How many test should I write?

One of my italian Friend once asked me “what is the percentage of code coverage that you consider enough for your tests?”. The answer is that probably there is not one.

If you write a project on your own you can set some limit (Es. 80% code coverage) but in my experience, in the real world, quite often you work in a team that does not use unit testing at all. Trying to introduce Unit Testing practices in a team it is a difficult stuff, we are always in a hurry, and the typical objection to testing is “I do not have time to write production code, how can I write test too?”. In my experience you should try to introduce testing in more graceful way, surely not setting some code coverage limit.

Another problem is that we often work on legacy code, usually absolutely not written with testability in mind, so it is really difficult to write good unit tests, that are not fragile, or erratic, or interacting, etc..

A good point to start is bug correction, whenever a tester signal you a bug, the first operation is trying to reproduce it in predictable way, you can try to write a xUnit test for this operation, when you have the test you can begin to work at the correction. If you write a unit test for each bug, you are sure that bugs never reappear in the software. This is usually a good way to introduce testing.

Another good moment to write test is when you need to modify a pieces of code written by another member of the team. The code can be commented, written perfectly, but modifying other’s code is not an easy task to do. In this situation you should begin to understand how the code works, so you can begin to write tests to verify your assertion. The great benefit of this approach, is that at the end of the process you have a good understanding of the code, but also a number of tests that makes you feel more comfortable during the modification phase.

More tests you write, and more you will appreciate them, do not try to introduce difficult metrics (like high percentage of code coverage), because you will only make developers hating tests.



DotNetKicks Image

Published by

Ricci Gian Maria

.Net programmer, User group and community enthusiast, programmer - aspiring architect - and guitar player :). Visual Studio ALM MVP

2 thoughts on “How many test should I write?”

  1. I generally just add some tests to get the coverage to some level and then configure CC.NET to break the build if it goes below. And then, gradually keep adding tests and fixing the metrics at higher level.

  2. This is a good way to proceed, but it is difficult to introduce unit testing in a team that does not adopt it beginning with a limit in code coverage. People that are not used to write test probably will write useless test only to reach that coverage.


Comments are closed.