Code analysis from an XP project – level 300
I’ve posted on a retrospective of my team’s current release, and I’ve run a few code analysis numbers to get a baseline trend.
I normally don’t do code analysis since working code is our real goal, but here it is:
I analyzed our latest component, which is a part of a larger software product. This component delivers tremendous business value, and it was developed from scratch on my team using XP methods. Here’s the stats:
Statements: 6600
Productions statements: 2500. The rest is test code.
Number of classes 141 – 71 production classes. The rest are test classes.
7.5 methods per class.
About 5 lines of code per method on average.
Maximum cyclomatic complexity of any method: 6. Average is 1.5
We have a few methods that are close to 20 lines of code, but the number of those can be counted on 1 hand.
This release has seen very few bugs
I don’t see any value in using code metrics as a direct measurement of the quality of the code. It may be a trend, but there is no causality between the two. It is, however, interesting to look at the trends from time to time.
- We ended up with 2 times as much test code as production code.
- Our classes ended up very small. Our methods even smaller.
- Our method cyclomatic complexity averaged between 1 and 2.
- We ended up with about 5 actual bugs in the release. This might seem unreal, but I credit all the automated test coverage for this result.
I know some of you will cringe at the thought of writing two times as much test code as production code, but given the results we have achieved, I consider it worth it.
It is really funny you would say that people would cringe when they hear you remarking about the amount of test code your team wrote. But the interesting thing is you can’t measure the amount of time that was cut from looking at a yellow line of a debugger. Probably the only artifact is the keyboards lasting longer, since the whole keyboard is used and not only the F10 and F11 buttons.
Another interesting fact I found was that the amount of time spent isolating a bug or issue also dropped drastically, due to the ability to validate the code quicker with existing unit tests. We found that probably 90% of our bugs where found in code that wasn’t covered by unit tests.
Maruis. Debugging time was definitely cut out drastically. Unit test do isolate issues as you state.
We found a couple of bugs in code, and as you say, it was code that didn’t have an integration test guarding it.
LoL, Maruis
Jeffrey, does this go throug?
Do you use nmock or similar things? if yes, how much? do you use unit test your UI code?
I used to use NMock, but now I use Rhino mocks. Rhinos are strongly typed whereas NMock relies on strings as the property constraints. I use mocks every time I unit test because I need to simulate dependencies. For UI code, I like the model-view-presenter pattern that allows the GUI code to be very thin, and I fake GUI and test the rest.