Improve Code Coverage Metric

 I know, every body knows that Code Coverage is a weak metric (Link). But there are two ways to improve the value of he code coverage metrics:

1. Remove all exclusion pattern
2. Remove integration test from the calculation

Point 1 should avoids that you cheat your self.

Point 2 is not so obviously but it's easy to explain. Integration tests ensure that the whole software or larger parts work. Unit tests are the result of TDD and code coverage could measure the TDD impact. That's the reason why only unit tests should part of the code coverage calculation.

Indicators for bad software design

There are many well known bad code indicator which are tested by different metric tools like PMD, FindBugs/SpotBugs, Sonar or ..

 

But there some bad software design indicators that are not covered by tools, at the moment. Remember these indicator works well for every day software development.

1. Test are not executable at my developer computer
2. Long test methods or test classes
3. Tests with conditions (if, ...)
4. Test with checks against a logger
5. Inheritance in test or in main code
6. Comments 
7. Byte code or class manipulation
   
8. ... will be extended
   

Not every indicator will point to bad code but in over 90% the indicator is right. I will explain the indicator in later posts. 

If you know a good indicator for bad software design. Please comment!

Test Coverage as Software Metric

The measurement of test coverage is often used as indicator of software quality. This is OK but be a aware of following interpretation of this number, if the test coverage is low that means:

1. You have to write tests
2. You are in trouble because your code is not developed in the TDD way and the code is not easy to extend or to maintain.

On the other hand if the code coverage is high, this means nothing. Or with other words: 

High code coverage != High quality code

Rule: Never Deploy on Friday

 

Many developers know the unwritten rule: Never deploy on Friday. The reason for this rule is that nobody wants to repair a live system at the weekend.

If you live this rule, it's a very good indicator for three things they are wrong in your software development:

1. Your application is not well tested for resilience e.g. with Chaos Engineering tools.
2. Your deployment pipeline is not stable enough or you not trust them and your tests.
3. Your not familiar with roll-backs or you have no feature toggles.

One of the major goal is to trust your software and the test so that you feel comfortable to deploy on every Fridays.

One of my major project goes online on Friday afternoon, most developers was not in the office, with success.