Bottom-up to TDD

In my current client project we have found the following a good way to add new behaviour to our web application.

A test for a web application depends on html details. But often we don't know these details when starting to write a new feature. So we first make the application output some hard-coded constant html. Sometimes this might even serve as a spike solution with which to practice some nasty integration, for example, but most of the time the data content really is hard-coded.

When we have manually verified that this one special case looks good, we can write a test for it (encapsulating the html details in a driver class). The hard-coded values can even be adjusted to match the test expectations so we have really done one feature, or at least one special case of it.

Now, with a working test framework, the the rest is plain old TDD: we just write one test at a time to show that some part of the html output needs to be parameterized.