My Testing and Code Analysis Toolbox

Last week we kicked of a “Testing Skill Group” at LINEAS, a group for exchanging knowledge about testing. One question that came up over and over again in various flavors was: What tools are there for testing and analyzing your code? So here is my personal answer for this, in the approximately order I tend to introduce them into projects:

JUnit: JUnit is pretty much the basis for everything else. Its THE unit testing framework for Java, with great integration in IDEs, build tools and CI Server. I don’t take the term ‘unit’ to seriously though. I use JUnit to execute all other kinds of tests as well.

Mockito: There are many Mocking Frameworks out there but I prefer this one. It has nice DSLish API and I find it nice to use. Only drawback is that in some special cases the standard API doesn’t work and one has to use an alternative syntax.

PowerMock: I actually try not to introduce this into projects. You need PowerMock if you want to mock constructors, static or final methods. If you need this, PowerMock gets the job done, but its better not to need it.

Jenkins: a free continuous integration server. Not exactly a work of beauty, but it works, is easy to setup and does everything I needed so far with the help of a couple of plugins.

CheckStyle: A static code analysis that finds lots of bad practices and can check lots of coding conventions too. Integrates in IDEs and CI server. There are other tools in this area which are worth considering: FindBugs and PMD. You can also use Checkstyle in order to gather simple metrics about your code.

JDepend: does static code analysis of the dependencies of your code. I use it to write tests against cycles between packages in the code and also in order to limit the dependencies to those I’m willing to accept in the code base. Some time ago I found out there are some limitations in JDepend resulting in dependencies that JDepend misses (I think it doesn’t consider classes in annotations or something). Therefore I’m looking at DependencyFinder, which seems to be way more powerful, but is certainly harder to use. I actually build a little tool for visualizing dependencies based on DependencyFinder.

Cobertura/EclEmma: Cobertura and Emma are code coverage tools. I use them both. Emma in the form of EclEmma as an eclipse plugin and Cobertura in Jenkins, because we couldn’t get Emma to work as we wanted on our Jenkins instance.

Sonar: It collects tons of metrics from your code and makes them available as a website. It actually to much numbers for my taste. In a serious project you can spend the whole day looking at numbers. What is really great about sonar is, that it tracks those numbers over time, so you can see if your average method length goes up or down over time. In some projects I configured a graph with the most important numbers plotted over time and added it to the main screen of Jenkins.

Reference: My Testing and Code Analysis Toolbox from our JCG partner Jens Schauder at the schauderhaft blog.

Related Articles :

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

2 Responses to "My Testing and Code Analysis Toolbox"

  1. Craig says:

    I think it’s a bad idea to run Emma locally and Cobertura on your build server because they can produce different results. If your build fails when code coverage drops below a certain level, you could encounter a situation where the build passes locally with Emma but fails on the build server with Cobertura resulting in a broken build.

    I have always configured projects so my team can run the exact build process locally as we run on our build server. This means that we very rarely have broken builds (usually when new guys forget to run the build process before they push their code to our repository).

  2. Alexian says:

    Is there any static code analysis for security? I always wondered and I never found anything like that, there were a plug-in for Eclipse provided by OWASP, but it’s a little bit out dated.

Leave a Reply


1 × three =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close