I’ve recently come across a few stumbling blocks where bad code got deployed, caused some damage, and then required a roll back or quick modification and hotfixes. While I have always written some amount of tests for the last few years, I’ve never been a huge fan of test driven development. The very idea that I have to spend hours writing up tests and mocking things to then spend just an hour or two writing the code to fix the issue seemed somewhat backwards to me and not an efficient use of my time. To a certain degree I think this somewhat depends on the scale your site is at and the affect it could have on any visitors or customers of your site. The larger your code base, and the sheer scale of your audience greatly affects the rate at which your unit and integreation tests begin to pay huge dividends.
This week I’ve decided to fully embrace full test driven development at least as a trial to see just how it affects productivity, speed, and developer happiness. In addition to getting back to TDD I’m also refactoring all the current uses of fixtures in my tests, instead now relying solely on factories to generate new instances of data and then test against them.