BACKGROUND
I’m writing a little game using Java, slick2d and other frameworks. Slick2d does not make it easy to write unit tests, but that’s something I can’t get around. One of the goals of the project was to have some test coverage but…
THE PROBLEM
Well… I wrote a 200-line test case, with 15 tests, and all for a class with only a single method.
I tested everything I could think of: invalid arguments, combinations of invalid arguments, swapping method calls and so on. I know I can’t test everything, and I know I don’t need to test code from libraries (Java API, slick2d API, logback API, etc.), but even in that case, I can get pretty crazy with tests, and I believe that I won’t be able to finish it if I write 15 tests for every method I create. So…
THE QUESTION
Where does good TDD draw the line at writing tests? Exactly what should I test, and what can I safely ignore?
OBS: For those of you wondering, the single-method class for which I wrote 15 tests was loading some strings into an array, and its method would retrieve the string, given the line and file as argument.
OBS2: I’m not skeptical of unit testing at all. I actually want to incorporate them in my project (whenever my API allows me) from the ground up. I just want to finish the project too, and don’t die writing tests all day long.
I would suggest the following book: http://www.amazon.com/dp/0321146530/?tag=stackoverfl08-20
from Amazon
Beside the book recommendation, When you design your tests, you have a lot of work at the beginning, but at a point, for every new code, most of your test logic will already be on place.
I would also suggest to make sure you are focused on intrusion prevention as well (code that test for SQL injection, buffer ovf and so)
Another point to remember is that when the one who wrote the code is the one who wrote the tests, you might want someone else that will try to break it down… not for everything, but at least for part of it.