As developers, back in university, we were taught to problem solve. Take a big problem, break it down into manageable chunks, and solve it one part at a time. Whether it was a group effort or individual effort, this strategy seems to work well, and I’m not complaining about it. Testing our program was to cover the code we have written and ensure that various cases were covered, after the code was written. Only thing with this approach to development is that sometimes, we try to hack a solution for submission and only testing to see if it works as it should. Sometimes, we get stuck and not know how to proceed.
Fast forward to today, where I have started working, and have been introduced to Test Driven Development (TDD for short). The same concepts about analysing a problem, and breaking it down to manageable pieces still apply. The only difference is that, instead of racking my brains to find the solution to that smaller problem, I solve the problem by writing one test at a time. Testing for one requirement of the problem at a time, and writing as little code as I can to get the test to pass, and repeat the process of Red (write a failing test), Green (pass the test), Refactor (clean up the code).
This concept may seem weird at first, but after trying it out for myself, I found it really helpful in keeping code simple and clean. Yes, I agree that it takes a longer time to come up with a solution, but, the solution will be of higher quality compared to say, when I hacked a working solution out. Next time you have a small assignment submission, pet project, or just a problem to solve, try using TDD and have a feel of how it works.
So what methods (or functions) do I test drive?
All of them I would say. This helps to get a piece of code that works properly before refactoring it to be a private method if required.
But private methods can’t be tested…
Yes, this is correct as well. However, when writing code, it is okay to set a private method as public and test drive the development of that method before setting it to private. Once the method is set to private, then the tests that was used to develop that private method may be removed.
Is it okay to do that?
Yes of course, tests are code too, and can be refactored as well. It is perfectly fine to clean up test code, by removing unused code, or even removing duplication in the test code.
Okay… do I write tests for all possible inputs?
Well, you can if you want to, but that could be quite a bit of effort wasted, and there will likely be inputs that you miss. A general rule of thumb is to have a test covering one zero or null input, a negative or invalid input, and a positive input.
With that said, it is not necessary to have a 100% test coverage of your code. There will be methods such as getters as well that does not require testing as the tests does not really add value to the program. On top of that, private helper methods which should not be tested, also will lower the test coverage. So there is no need to worry about not getting 100% test coverage. However, do be sure to cover different exit paths in the method you are testing as well.
Here is a book if you are interested in reading up and learning more about TDD.
tobie.w 