Re: OOP/OOD Philosophy
- From: "Phlip" <phlip_cpp@xxxxxxxxx>
- Date: Thu, 14 Jul 2005 22:19:08 GMT
hansewetz wrote:
> I can't put them together since you don't present a single strategy
> for testing.
I said it over and over again. You could probably repeat it. Unless you
moved the definition of "strategy"...
> At least I can come up with a few strategies for analyzing
> problems, solutions and problem solving.
At least I can too. I hold them subservient to you-know-whats.
> For example, I can choose to develop a meta model for my domain. I can
> then show that any model instantiated from the meta model has certain
> characteristic I want it to have. I can also enumerate the different
> elements I will use in my model. For example, I may choose to use
> entities, events, values, etc. - each being well defined. When I
> solve a problem I have multiple problem solving strategies available:
> solve difficult parts first, solve easy parts first and hope the
> difficult ones disappears, generalize the problem and maybe it becomes
> easier to solve, map the problem into mathematical notation and apply
> mathematical analysis, remove assumptions - maybe the assumptions
> prevents me from solving the problem, reformulate the problem, solve a
> similar problem to get hints, etc.
That is orthogonal, at least, to the goal of tests driving development. Of
course you still need to do all that, but...
Can you put an 'assert(false)' anywhere in your code, run all your tests,
and get failing test cases? Done right, you should at least fail "unit"
tests, and each of these should associate with a user story. And you will
very probably fail an acceptance test, and this _will_ associate with a user
story. (Done perfectly, an acceptance test _will_ fail, but that's more
perfect than most development needs.)
So in your scenario, you have tangled this traceability up into an elaborate
object model. It's a fine model, and a fine system to generate it, but my
thought experiment illustrates how your system is not necessarily driven by
executable specifications derived from requirements derived from field use.
> I could see a few test related issues that should be analyzed. You may
> want to build tests that detect simple code bugs - i.e. the design
> has been coded incorrectly. You may want to build tests that show that
> the design or algorithms are logically working according to
> specifications. You may want to build tests that show that there are no
> inconsistencies among different behaviors in the software. There are
> probably many other categories of tests that may be done. I'm not
> saying it is possible to practically separate tests this way since you
> are applying tests on something that implements a mix of concerns.
> However, it is probably worth giving it a shot - maybe someone has
> already done it. Or, maybe you are already doing it ...?
Yes, we hire QA departments to add these kinds of tests that target coverage
and combinatoric issues. Our QA has a much easier time of it.
And unless you use SPARKS, we debug much less than you.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
.
- Follow-Ups:
- Re: OOP/OOD Philosophy
- From: hansewetz
- Re: OOP/OOD Philosophy
- References:
- Re: OOP/OOD Philosophy
- From: Mark Nicholls
- Re: OOP/OOD Philosophy
- From: Robert C . Martin
- Re: OOP/OOD Philosophy
- From: hansewetz
- Re: OOP/OOD Philosophy
- From: Robert C . Martin
- Re: OOP/OOD Philosophy
- From: hansewetz
- Re: OOP/OOD Philosophy
- From: Phlip
- Re: OOP/OOD Philosophy
- From: hansewetz
- Re: OOP/OOD Philosophy
- From: Phlip
- Re: OOP/OOD Philosophy
- From: hansewetz
- Re: OOP/OOD Philosophy
- Prev by Date: Re: Power of OOD, silver bullet and you
- Next by Date: Re: Getting Started with UML
- Previous by thread: Re: OOP/OOD Philosophy
- Next by thread: Re: OOP/OOD Philosophy
- Index(es):
Relevant Pages
|