The Science of Test-Driven Development
Mark Seemann helps programmers make source code easier to maintain. In this excerpt from his book, he provides a simple way to test your code.
From the book
From the book
The Red Green Refactor process is one of the most scientific methodologies of software engineering that I can think of.
The Red Green Refactor cycle
In the scientific method, you first form a hypothesis in the form of a prediction of a falsifiable outcome. Then you perform an experiment and measure the result. Finally, you compare the actual to the predicted outcome.
Does that sound familiar?
That sounds like the Arrange Act Assert pattern, although we should be careful not to overextend the metaphor. The act phase is the experiment, and the assert phase is where you compare expected and actual outcomes.
The red and green phases in the Red Green Refactor cycle are small, ready-made science experiments in their own right.
In the red phase, the ready-made hypothesis is that when you run the test you just wrote, it should fail. This is a measurable experiment that you can perform. It has a quantitative outcome: it'll either pass or fail.
If you adopt Red Green Refactor as a consistent process, you may be surprised how often you get a passing test in this phase. The brain easily jumps to conclusions. You'll inadvertently write tautological assertions. Such false negatives happen, but you wouldn't discover them if you didn't perform the experiment.
Likewise, the green phase is a ready-made hypothesis. The prediction is that when you run the test, it'll succeed. Again, the experiment is to run the test, which has a quantifiable result.
If you want to move towards software engineering, and if you believe that there's a relationship between science and engineering, I can't think of anything more appropriate than test-driven development.