Developers strive to write their code as good as they can. Then they try to refactor it in order to make it clearer and more maintainable. How we can make sure than it improves over time?
First of all we need to measure its "quality" in order to know what is its current level. Of course quality is not a well defined word. We need some quantitative metrics to measure quality. There are many metrics that could be defined, one of them is Code Coverage. Code Coverage tells us how many percent of the code is covered by tests, i.e. tests pass during their execution on that code. High Code Coverage indicates that the majority of the code is tested and works properly (at least as defined by tests). It does not mean that our software does not have bugs. But it gives a high level of confidence in what the software does. On the other hand low Code Coverage indicates that we don't know anything about the code, whether it works or not.
Let's see how we can measure Code Coverage using TeamCity's build in dotCover. On the the Build Steps page, click Edit on your test step, whether it is NUnit or MSTest:
On the .NET Coverage section, select "JetBrains dotCover' in .NET Coverage tool. dotCover is a build in coverage tool within TeamCity. In the Filters section specify assemblies that you don't want to cover, for example your tests assembly.
Run the build and navigate to Code Coverage tab under build:
It will show the the total Code Coverage per class, method and statements with the option to drill down. The most important number is the percentage of Statements Code Coverage. In the below project it is 34.8%. Which means that approximately third of the code is covered by tests.
Now given the current level of our Code Coverage we would like to make sure it only increases. We are going to define that if code coverage decreases, the build should fail. It means code coverage is one of our failure conditions. In order to do that we navigate to Build Conditions page and click on "Add failure condition" under "Additional Failure Conditions" section. On the dialog that appears we define as follows and click Save.
Then you can define some more failure conditions on every metrics:
Having defined those settings we can assure that our code coverage will increase over time. But is it enough? Of course not, our team will not produce better code just because we set these automatic failure conditions. It need to be trained how to identify code smells, how to write clean code, how to write proper unit tests. It is a long process and requires good coaching.
Let's summarize what we had until now on how to improve your code quality:
1. Define metrics that important to you and measure their current state.
2. Make the measurement part of your continuous integration and define failure conditions on its decrease.
3. Train your team on how to write better code, write good unit tests.
I'd like to read your feedback on how it is done in your company.
P.S. The screenshots above are taken from an OSS project I am contributing to called BizArk. Its continuous integration is generously hosted on Codebetter's TemCity server. TeamCity is provided for free for open source projects by JetBrains.
