test objects design

Domain-Driven Design: What Is It?

Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, teams need an extensive set of design practices, techniques and principles. Refining and applying these techniques will be the subject of discussion for this site, generally starting from the language of patterns layed out in Domain-Driven Design, by Eric Evans.

The above quote is a departure point to speak about static versus dynamic view of software requirments and tests. In my experience most business requirements I see are static snapshots, however software has a dynamic behaviour.
Most requirement documents are written in a linear descriptive language but user interaction with software doesn’t work at that level of linearism most of the time. It’s more like a non linear generative behaviour. Most methodologies describe test case creation as step by step instructions that model process but most testers (exploratory tesers) find bugs when they model objects and set up states and move from state to state and trap illogical integration holes that were never thought out.

By modeling requirements you can find conflicts and contradictions and big gaping holes because you model approaches, interfaces, existence, movement, relationships and stuff that you could never do in a step by step linear test execution. As the saying goes “A picture is worth a thousand words” so in requirements and use case scenarios a model or a set of models is worth at least 30 pages of linear descriptive step by step English language statements that most people will not have time to read - and most will not comprehend… and worst of all - a lot of programmers will not use to derive the behaviour of the system because for many English is a second language.

The properly structured ‘the system shall’ statements approach to requirements is a very very costly way to develop software. That language must exist on many projects because of regulatory and contractual commitments but a Domains Specific vocabulary ought to be derived that is behaviour specific and maps to business rules

Many times requirements are divided structurally into units however software works at the level of behaviour, interaction. The organizing structural principle is collboration, interaction and not structure as a collection of units standing next to each other. With that kind of static view of units next to each other Integration becomes very costly and occurs too late in projects. Dave Astels writes “We shouldn’t be thinking about units… we should be thinking about facets of behaviour”. Of course he was talking about context of an object and testing not just a method but specific behaviour in a specific context no matter if it’s a method of one object or many objects collaborating; So maybe we should be thinking of this not as Functional Test Design but Aspect Test Design. Another sense of this is: Aspect is holographic, Functional is linear. With Aspect you switch context or you reside in context from which you see test. You can switch context and reside in a new place from which you see a different family of tests - can you automate such testing? Sure you can. But the automation at this level is not a step by step execution of tests against an application using WinRunner or Watir or whatever automated test tool you have. I think it’s too early. First you automate your context creation by generating activity diagrams. You automate by modeling objects and describing their behaviours.

You distinguish software. you don’t describe it. You distinguish test cases, you don’t describe them. Thoughts?