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 :

Related Whitepaper:

Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions

Get ready to program in a whole new way!

Functional Programming in Java will help you quickly get on top of the new, essential Java 8 language features and the functional style that will change and improve your code. This short, targeted book will help you make the paradigm shift from the old imperative way to a less error-prone, more elegant, and concise coding style that’s also a breeze to parallelize. You’ll explore the syntax and semantics of lambda expressions, method and constructor references, and functional interfaces. You’ll design and write applications better using the new standards in Java 8 and the JDK.

Get it Now!  

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


× 6 = twenty four



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.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books