For pure curiosity reasons, I wanted to know the ratio of lines of code to unit tests. I’m writing all production code in Java and tests in Groovy.
Finding the lines of code: grep -v -r –include=”*.java” “^[[:space]]*$” * | wc -l
grep -r –include=”*Test.groovy” “@Test” * | wc -l
LOC: 706, Tests: 82
This yields a ratio of: 8.6 to 1
I’ve actually been coding a lot at work recently. The system I’m building at the low end interacts with a Web Service to retrieve data. At the high end, it reports this data in custom forms and at configurable intervals. I’m building a few different API layers in between. A small, convenience API that interacts directly with the Web Service to simplify gathering of data. On top of that, I have several more wrapper-style APIs that allow the developer to work with the generic data types as wrapper objects for what they really represent. On top of those is the framework for forming and sending off the data to another system.
In this situation, I knew what the system must do, but not the exact details of how it would work at the lower levels. I did enough work on a POC interaction with the Web Service to know that the basic direction I wanted to go was possible. At first I took straight to developing the lowest level API, as that’s where I had my most detailed requirements. From the knowledge I gained doing the POC, I had enough to start there. However, in the end this hurt more than it helped.
After TDDing my way through several of the requirements I had of the low level API, I found myself in a sticky situation.
1. Too many tests tied too closely to implementation
2. I felt like I was progressing a little slowly, having to stop and think too long about what needed done next
3. I ended up having to heavily refactor about 2-days worth of code because the tests I came up with, did not reflect the true needs of the system
Luckily at that point, I realized right away that my lack of higher-level tests were allowing me to steer the system off path. I needed these higher level tests to drive the requirements for the behavior of the lower level API. So, I started fresh, writing a single acceptance level test that defined a small feature of the system. I continued to work my way down writing more tests until I couldn’t write a smaller more precise test without controlling the implementation details. That was my cue to start coding, and get all those tests I had written to pass.
The results..
1. Just enough code to meet the requirements. No more, no less.
2. Fewer tests tied directly to implementation details
3. A thin, vertical slice of functionality