My Testing and Code Analysis Toolbox
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 :
- Rules in JUnit 4.9 (beta 3)
- Spring 3 Testing with JUnit 4 – ContextConfiguration and AbstractTransactionalJUnit4SpringContextTests
- Testing Techniques – Not Writing Tests
- Diminishing Returns in software development and maintenance
- Services, practices & tools that should exist in any software development house, part 1
- I am not an engineer – I’m a software developer
- Agile software development recommendations for users and new adopters
- Java Tools: Source Code Optimization and Analysis
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… Read more »
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.
I created a system for similar purpose: