A way to specify behavior

The modern name for an ancient programming technique —which roots can be traced back to Dr. E.W. Dijkstra*— was “test-first programming” and didn’t preclude, in any sense, the need of validation and verification testing, done by an independent group of people with a different mindset and goals (whereas programmers want to release the best possible software, the testers want to stop releasing software with any lurking bug).

Seasoned testing professionals usually have a bunch of techniques for testing existing software based on already specified behavior, and these professionals have been able to do just well without “test-first programming”. An important project (is there any that not?) could not afford to go without these professionals and any attempt to dismiss their importance because of a programmer’s technique is a recipe for disaster.

On the other hand, test-first programming is a way to specify behavior and to build trust that the specified behavior is kept in place while the software grows in capacity.

* “Instead, you construct a correct program in small steps. Each step takes the specification and produces something a little nearer to the final program. Each step is small enough that you can see exactly what needs to be proved to show that the step is correct.”
The Professor Edsger Wybe Dijkstra school of thought (aren’t these the eXtreme Programming test/code/refactoring micro-cycles?)

Skip to main content