During today's coding session of our Scout IT Day (ImmobilienScout24's flavor of the FedEx or ShipIt Day), I spent some hours to clean & refactor the unit tests of the Analyzer implementations.
I'm pretty happy with the results: for example, have a look at the test of the ServletContainerInitializerAnalyzer. It now consists of only 37 lines instead of 56. What's more important: it's much more readable & understandable now (besides the fact that as a non-native, my English could certainly be improved).
Tests are more important than production code
With clean code, software craftsmanship at al. people started to write better code. Unfortunately, that was oftentimes only true for "real" code; test code was left at an awful decaying state. It's funny to note that not so long ago, developers being new to a team were only allowed to write test code, not production code. Whereas I think it's the other way around. When I was assigned to a new team last year - me having that funny role of an software architect, I am shuffled around every now & then to where "the important" things are happening -, I made the team focus on tests primarily. And I didn't shy away from implementing test code, the software architect I am.
And here's why: tests, representing the business requirements, are here to stay, while productive code changes with every feature and refactoring. And if your test code is crap, you end up changing twice, thrice, umpteen times more test than productive code. And because your test code is crap, it takes you twice, thrice, umpteen times longer to understand what you are doing. And because that darn test code is crap, you're doing twice, thrice, umpteen times more faults than with your productive code.
So after some TDD and increasing test coverage, I noticed some developers getting reluctant to writing tests - because they feel they their doing more harm than help ("I need to change the tests along with the implementation anyway, so what can they detect besides the fact that I changed the code?").
And it's gone!
Now what? "How do I write better test code?" you ask?
I'm certainly no expert, but I bet if you embrace test code as "the real deal" and approach test code with your best clean code attitude, you'll find the answers. Name things correctly, extract common logic, use Test Data Builders, etc., you know - be a craftsman. You'll get there.
About deadcode4j
deadcode4j is a Maven plugin which finds dead code. To use it, go to the console, navigate to your Maven project, type
mvn de.is24.mavenplugins:deadcode4j-maven-plugin:find ‑Dmaven.test.skip=true
and see what it finds.
Hop on over to GitHub to learn more, browse the code, or contribute.
Here you can read how it all started.
