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?)