Why TDD?
6/7/2017
It’s week 9 at Makers, and I’ve noticed a recurrent theme: the importance of TDD (test-driven-development) and why people (i.e. me) struggle to get round to doing it.
So I’m going to write three blogs on TDD addressing why TDD is important, how to do TDD, and possibly most importantly, how to motivate yourself (me) to do TDD better.
So here are some questions about why programmers should bother with TDD:
1. Why not just write the code correctly in the first place?
Definitely a good idea to write good code — but your code will inevitably change. Example: I wrote a rails app a few days ago and used the Devise gem for user authentication. I wanted to style the forms, so I changed some buttons to a link. I was proudly showing off my beautiful creation to a friend when the buttons stopped working (good tip: rails forms default to a POST request and you have to specify if you want GET — I hadn’t done this, which is why my code broke). If I’d had a feature test, I would have known right away that my routes had broken when I changed the form.
2. Doesn’t writing tests takes away time from adding features?
But it gives you the time back in debugging those features later. Even if you manually inspect your site (for example), you still have to reload the server (depending on which server you’re using), possibly clear the cache, and run the tests yourself. Much easier to run RSpec (or whatever testing framework you use) and have it tell you the exact line of the error, and possibly even how to solve it.
3. Wouldn’t you rather be writing features?
Doing good work means sometimes you have to do something that’s less fun in pursuit of an overall goal. Violinists play scales, athletes do something athletic, programmers write tests. It’s part of the less glamorous part of our job that means we are way better at our job. And we want to be kickass programmers, right?
4. But doesn’t writing tests just make the whole process slower?
Not so much slower as break it down into smaller steps! The idea of sitting down at a machine, typing furiously for six hours, and emerging with your keyboard smoking and an amazing app fully developed is really sexy. But even if you manage to do that perfectly, your app will have to change — and possibly even be changed by someone else who may not have your brilliance and depth. Much better to code in tiny pieces, each new bit being tested so you can immediately pinpoint problems.
5. Is there anything else great about tests?
Yeah! They satisfy the XP value of communication: tests tell the next programmer maintaining your code what exactly it’s meant to do. I’m struck by how often my coach asks to see my tests — it’s a quick way to get an overview of what the code is meant to do. Also very importantly, tests demonstrate that you’ve accounted for edge cases — so think of them as an opportunity to show off how expansive your thinking is.
Ok, so that’s it for post one. Check out the next one: 5 Steps to Good TDD
