Bil Simser posts about his team’s mottos which he hopes will keep them on track writing tests.
I agree with Bil that the only way you can refactor with confidence is if your team has confidence in its tests. But, even doing TDD I have bee on teams where we had tests but not really enough tests to be confidant that everything that could break was tested. As a result we never had the confidence in refactoring that we should have had. I have found three things important in keeping your tests up to scratch:
1: Follow the deliver frequently mantra and write small tests that take you estimate to be no more than 10-15 minutes to get finished and potentially even shorter. This seems to make sure that you test at the right level of granularity and get enough tests, because you have to break the problem up in digestable chunks.
2: You should keep a test list either scratched on paper, or on notepad it does not matter, but have a place to record tests that occur to you while you are writing your current test. This helps you focus on the now, but it also helps reduce the amount of speculative code you write, because you know that you have a test coming up that will push the need for that code later, so if you do not need it now you will not feel compelled to write it in case you forget. The trouble with the latter is it easy to forget the associated test.
There is nothing new here. Kent Beck covered all of these in Test Driven Development By Example
3: Use an integrated code coverage tool (VS 2005 and Test Driven.NET have these) so that you know whether there are parts of your code that are not tested. Aim for 100% code coverage. You will not hit it, some things are hard to get under test, but if you aim for a lower figure you are stating that you only want that percentage of confidence in your code. Where you have code that is hard to get under test I would recommend abstracting that dependency out into its own assembly and replacing it with a mock that you can test. That isolates the ‘hard to test’ code from the testable code. Usually it gives you a better architecture because things that are hard to test are often things we should not depend on.
Get in the habit of having one code fixture per class under test, so that you can run just that fixture and see if you have 100% code coverage for it. If not figure out why (sometimes the code coverage tool may give anomolous results – record this in the file). If you have code that you think you do not need to test ask yourself why it is there. If it does something it can break, if it does nothing why keep it.
We published our guidelines here.