XDepend Blog

Nowadays TDD is considered a best practice in software development. One of the goals of TDD (or side effect) is to have a 100% coverage on your application code. This will often mean that you have as much test code as application code, or even more. In some contexts you might also consider using tests as documentation. As a result, it is obvious that the code quality of tests should be considered as important as the code quality of the deployed code.

Analyzing your test code with XDepend is quite straightforward. You would start by creating a jar of your tests with the following Maven command:

mvn test jar:test-jar

Then you would open XDepend and create a new project and select the jar you just created for analysis (we don't necessarily need to add the dependencies since we're not gonna focus on the architecture with the external jars; the analysis won't break, XDepend will just put all the external dependencies in a generic jar named "MISSING").

You can then launch the analysis and start by taking a look at the built-in CQL queries. Indeed the regular code quality and design rules apply; test methods shouldn't be too long, shouldn't have a cyclomatic complexity that is too high, etc...

Next you can perform specifically tailored code queries that take into account the fact that you are analysing the quality of your tests. Take this request for example:

SELECT METHODS WHERE !(IsUsing "junit.framework" OR IsUsing "org.junit") 
AND !IsConstructor AND ReturnTypeIs "void" AND !NameIs "setUp()" AND IsPublic 

This request will help you find useless test methods ; a test method which isn't using any assertion is useless, however sometimes some of these happen to be committed after an intense TDD session, or perhaps someone in your team isn't quite clear about the best practices for writing tests and needs a refresh.

Once you will have set up the custom queries for your test jar in addition to the default ruleset, the next step is obviously to include the XDepend analysis of your test jar in your continuous integration build in order to maintain, or much better, improve the quality of your tests over time. Start improving the quality of your test code and you can be sure that the quality of your application code will also see a positive evolution (well, at least I think so, be sure to let me know in the comments if you disagree).