The unexpected benefits of TDD
Hi there! Do you know what TDD is? It’s Test Driven Development.
To tell the truth, no, I don’t do proper TDD: technically, you’re supposed to write the tests before you write the code, and while that’s a nice thought, not being able to write the ideas in my head down immediately gets in the way of the creative process. Tests are the equivalent of “editing”: writers of all types and kinds write first, and then edit, sometimes almost endlessly. That’s why it’s called “polished” writing.
There are a couple important benefits to TDD: better architecture of your code and less tightly coupled code, code technical quality (less bugs, in short), and documentation through code. However, there’s one more benefit that I hadn’t run into until recently: tests help maintain backwards compatibility.
True, sometimes you will have to rewrite your tests when you modify code — but please, it should at least make you stop and think twice.
There are two things going on when you modify your tests:
- Every project has externally facing methods and classes (your API/SPI) and internally facing methods and classes (code used only internally by the project itself).
- You should be aware of what your test actually tests. In short, you should separate and write your tests according to whether they deal with externally or internally facing code.
When you modify your test, and it tests externally facing code, then that should trigger a realization about what you might be doing to users of your project.