My team at work has recently started doing Test Driven Development. Prior to this we had tests but they were almost always done after the code was written and they weren’t comprehensive.
Now things have changed. Now we’re writing tests first and they are an important focus. It’s sometimes been difficult to get used to and change the way you think but in the end it’s been extremely worthwhile.
As I’ve started this process I’ve made some observations that are noted here.
- You absolutely need to make sure your tests fail after you first write them. Several times I wrote a test but didn’t ensure it was failing only to realize days or weeks later that the test wasn’t working at all and the the success what mistaken.
- It changes how you write your code for the better. Easily testable code generally seems to be better, more modular code. For instance, rather than make one very large function that is a couple hundred lines long, you’ll instead break it down into 4 smaller, simpler functions to make testing each individual part easier.
- You can write a bunch of stubbed out tests that serve as a to-do list of sorts for what you have left to implement. No more separate .txt files with a list of tasks.
- Once you complete your tests they serve as documentation for what you code should do. When you see a test that says
should blink the screen red and black you know that the code being tested should make the screen blink red and black. This is really nice when you’ve been away from some code for a while or you are looking at another developer’s code. Since you’ll be updating your tests as you update your code, this form of documentation will always be up to date.
- After practicing TDD for a while you’ll find yourself going back and wondering why on earth you tested some of the things you tested. The fact of the matter is that it takes some time to develop the experience necessary to know what to test and what not to test. It isn’t always easy at first but if you keep at it you’ll get there and see the quality of your tests improve.
- You quickly lose confidence in untested code. Seriously. It’s crazy how fast it happens. Maybe a week after I started doing TDD I noticed that when I went to develop a quick feature without tests it didn’t take long before I was feeling very uneasy about the correctness of my code. If I had been building this feature a month earlier I’m not sure I would have given it a second thought.
- It gives you a sense of accomplishment. There is something satisfying about seeing a bunch of successful tests and, for me at least, is somewhat motivating.
- Don’t worry about testing everything. Instead focus on testing code that is mission critical or complex. For instance, if there is some core code used by the entire app it’s probably worth while to make sure it’s tested. But have an object that is only getters and setters? It’s probably not worth testing unless they have some complex logic inside.
- For the love of Pete please make sure you are running the tests all the time. At the very least run them before pushing any changes. It’s incredibly frustrating to pull the latest changes from version control only to have the tests broken. Don’t do that to your fellow developers.
- Keep the number of assertions in each test down. When I started out with TDD my tests would often have many assertions. When there was a failure though, it was difficult to determine what assertion was failing. It’s much easier to spot the failure if you have a limited number of assertions in each test.
- Don’t make your tests depend on other tests because it will make them fragile. You’re just asking for trouble if you do.