TDD and the Scientific Method

TDD’s mantra is the following: Red, Green, Refactor. In other words: write a failing test, write code to make it pass, and then make the code better (with the test as a safety net).

Comparatively, here are the steps of the Scientific Method:

• Ask a Question
• Do Background Research
• Construct a Hypothesis
• Test Your Hypothesis by Doing an Experiment
• Analyze Your Data and Draw a Conclusion
• Communicate Your Results

There are many parallels between these two disciplines.

Writing a failing test can be compared to asking a question: “Can my application do this?” The constructed hypothesis is that “no, the application can’t do this yet” (if it can, we just skip to the next iteration).

Writing the code to satisfy a test can be compared to doing the experiment to confirm the hypothesis.

Refactoring can be compared to drawing a conclusion and summarizing your results. Based on what you’ve learned about the application’s behavior, you can rearrange the code so it tells a much better story of the application’s intent.

Of course, it’s not an exact parallel. You’d be scorned in the scientific community for filtering data and only using the data that advances your hypothesis (see confirmation bias), but otherwise, the similarities are striking.