My take on test driven development

June 09, 2019

If you do formal Test Driven Development (TDD) there are some rules for how you should do it, like you start with the test, then you write a failing test, but not more than to make it all fail. Then you fix it, add another test etc.

I’m not into this for a number of reasons, but I do agree with the basic idea: you don’t write anything without also writing tests to make sure it works. It takes some time, but it will save you a lot of time as you move forward.

This is how I do it for backend code:

  • I write the controller, and then the services behind it, plus model changes etc that are required for the controller to do what it needs to do. Sometimes that also means so extra filter/middleware stuff etc.
  • When the code makes sense I write tests for it.
  • I exclude what I don’t need to test (classes with just setters getters) or can’t test
  • Write unit tests for the rest
  • Finally I write a test in Javascript that use the controller over HTTP

The big difference between them is that I only care about making sure there are good tests in place by the time I’m done; how you do it isn’t that important.