For the vast majority of business software being build from scratch this works fine. It will fall down when the requirement itself is technical or you are faced with implementing on top of an existing system (eg modifying SAP).

When implementing on an existing package requirements and hence test cases have to reflect the underlying technology in use, and its the role of the professional business analyst or solutions architect to help the business shape requirements so that they can be easily implemented in the pre-defined technology.

Its not difficult (conceptually) it becomes difficult due to people issues such as office politics, poor management and poor communications.

Look for example at puzzle.rb and its tests in puzzle_spec.rb. The primary functionality that puzzle class should supply is that of solving the puzzle. Yet, the tests are not focused on this functionality. Instead the tests examine the underlying decisions.

On the one hand this may seem as testing impl. rather than functionality. On the other hand, you can literally see the TDD evolution of the class and get a sense of the particularities of the algorithm without looking at the code, which is neat.

Like anything, you can do TDD wrong, but that does not mean you should not do it.

What about duplicate content? They are both posted by me.

Very good post. My most recent blog post has a similar theme. I had a different take on what software testers can learn from manufacturing though.

My blog post is here: http://hexawise.wordpress.com/2009/08/25/what-else-can-software-development-and-testing-learn-from-manufacturing-dont-forget-design-of-experiments/

There are more similarities than most people realize between manufacturing and software testing (and more lessons to be learned from proven manufacturing practices than most software testers realize) . In manufacturing scenarios (such as making transmissions and engines), before a final design is arrived at, prototypes are constructed. There is a science to creating as few prototypes as possible and learning as much as possible from each prototype. The field is known as Design of Experiments and firms like Toyota and Ford have followed DoE principles for years. The analogy in software development during this phase is Google’s web site optimizer. It allows developers of web apps to experiment with different layouts and learn (with as few “prototypes” as possible) which works best. After the Design of Experiments prototyping is completed, the “best product” should be tested. This step is not typically considered “Testing” by QA/Testing organizations, but the next lesson learned is…

Design of Experiments methods can also be used in QA / software testing. With a goal of finding as many defects in as few test cases as possible, Design of Experiments-based test case identification methods (such as pair-wise, orthogonal array-based, and n-wise approaches) have been proven to find more than twice as many defects per tester hour as standard, manual methods of test case identification. Links to an IEEE article backing that statement up are included in my blog post.

- Justin

[Test]
public void ShouldSortOnDate()
{
GivenSort(SortBy.DateDescending);
WhenPresenterInitializes();
ThenDateSortIs(SortDirection.Descending);
}

Hiding the implementation details in helper methods allows the tests to read like stories and gives the next person who comes to the tests the description of the behavior of the test prior to them needing to look at the nitty-gritty of the implementation details.

I would apreciate some code examples of story-like tests