Martin Albisetti's blog

Why test driven development rocks

All projects in Canonical have a strong focus on testing. From all of them, I think Bazaar ranks the highest on obsesiveness on testing. As a drive-by contributor, it always felt like a very high entry barrier, and deterred me from getting into complicated changes. It was only after I bit the bullet and got into more complicated changes (in Launchpad, actually) that I understood that tests where my best friends ever. It's a safety net against myself, and actually lowers the barrier, because I don't need to know about the rest of the code base to make a change, tests will tell me if I break something (seemingly) unrelated.

On the more extreme side, there is test driven development (TDD). You write the tests first, watch them fail, and then start producing the code that will get them to pass. Having co-authored bzr-upload with the TDD-obsessed bzr developer, Vincent Ladeuil, I thought that if I was going to add a new feature, I may just as well try it (again).

It rocked.

I set up the test, my carrot, and the task went from "start poking around code" to "fix this problem". With the test written, it became very clear what parts of the code I needed to change, and how the feature had to work.

The results?  in one hour, I implemented a feature that lets you ignore specific files on upload. With tests.