Cobertura has an Eclipse plugin, but it's suffering from neglect. So I'm putting a small bounty on it. $250 to the person who gets it back up and running.
My requirements for the plugin?
-Runs Cobertura from within Eclipse
-Highlights your tested and untested source code
-It'd have to run to one of the core committer's satisfaction. When they're happy, I'll mail you a check. It's not a ton of money, but it's a few dollars.
There you go... there's a file in the build (eclipse-plugin.zip) that'd make a fine starting point.
Given that so many people at are Java One this week, it might be a bad time to announce this... on the other hand, with so many people busy, it might be ~your~ chance to get a head start. :)
And Java 6 arrives with a bit of controversy.
Ted rants about the lack of a 32 bit version in Why, Apple, Why?
In a nutshell, if your Mac has a Core Duo CPU, you're running 32 bit. You must have a Core Duo 2. (see this Wikipedia entry). Oh, you must have Leopard (10.5.2) as well.
Here's a great post that shows you how to make 1.6 your default Java. The Apple installer doesn't do that... apparently they don't trust the version enough to be the default Java on your box. Not inspiring confidence with that decision...
Man, I really love Ruby.
Jeff Brown is a great speaker and we're lucky to have him coming in locally. If you're tinkering with Groovy or Grails, or thinking about it, I strongly encourage you to come out tonight and pick Jeff's brain.
In addition, since this is a NFJS sponsored trip, a free pass to the Research Triangle Software Symposium will be raffled off.
You'll find more info about the meeting and directions at The Triangle Java User's Group web site.
I'm often asked what static code tools I like for Java. First, I've been nearly full-time in Ruby and Rails for a year now, so I may be out of date, but here's what I like.
Findbugs
Findbugs is the absolute best tool for static code analysis. But best is a nebulous and somewhat relative term. I prefer something with a very low noise to signal ratio, and Findbugs has that. Other tools (like PMD, see below) report a lot more information. So much in fact that real issues can get lost in the clutter.
Here's a quote for you... I've never run Findbugs on a production codebase and not found at least one legitimate bug. A real, not theoretical, issue.
Findbugs is free (open source even!) and the rule set can be edited with an XML file. They have an online (Java Web Start) version, Eclipse plugins, and more. It's an all around a great tool.
PMD
I don't like PMD as much because it has so much information in the reports. The good tends to lost in the false hits. However, after you've gotten your product in good enough shape that Findbugs runs cleanly, then PMD is your next step. You'll have to work a bit harder to find the good results, but it's worth the effort.
CPD
A real gem in the PMD toolbox is the invaluable Copy/Paste Detector (CPD). This tool will scan your entire codebase and point out every place where someone has lifted a bit of code.
The problem with the copied code is when you fix a bug in one spot, the fix is rarely copied around to all the pasted code. When you spot duplicate code with CPD, take a long hard look and see if you can't pull that code into a utility class. This won't catch everything that violates the DRY principal, but it's a good start.
UPDATE:
Tom Copeland sent me some extra CPD information. CPD also has a web-based launcher here so you can try out CPD without having to install the entire PMD suite. He also mentioned the PMD Applied book and said that chapter 5 goes into great detail on CPD.
Thanks Tom!
Code Coverage
You should be running a good code coverage tool to see what code your automated tests hit (or your manual tests for that matter). There are several great tools available, but I'm partial to Cobertura. It's a solid tool with great, easy to read reports. There are several other great tools available (Emma and Clover come to mind).
I'm not religious about my code coverage numbers... I don't think you need to set a code coverage number and make it a goal. I'm more concerned with using code coverage as a guide to direct my efforts.
Another tool inside Cobertura that you can use to direct those efforts is the Cyclomatic Complexity number. I've found it to have a direct correlation to code with bugs. The more complicated the code is, the more likely it is to have problems.
Continuous Integration
How often and from where should you be running these tools? Every time you touch the code of course. You don't want out of date reports do you? :)
Read Martin Fowler's classic article Continuous Integration, then go download the binary release of Cruise Control. The latest release has a nice Dashboard (see Jeffery Fredick's blog entry about the 2.7 release.)
I like to roll my static code tools into an Ant task and then run them from within Cruise Control. I publish the reports as part of the project's artifacts. This ensures things are always up to date, as well as providing a historical reference point I can revisit.
There are other popular CI tools available to you as well. These days Bamboo and Hudson are becoming more popular. This CI product matrix is a little out date, but a good starting point if you want the lay of the land.
Agitar
I've pointed you at a lot of open source tools... let me point you at one really big commercial offering. Agitar covers most of what I've listed above, and a lot more, including automated test generation. (Never let those automated tests replace a culture of great hand-crafted tests... use them to supplement, not replace.) Some companies just feel the need to have a commercial product in place. If you work there, check out the Agitar suite.
How Much?
If you put too many analysis tools and reports on a single page, developers tend to ignore them all. Pick one or two at first. This blog entry is a nice write up of one of my favorite strategies.
I hope this gives you a few options to check out. Just be sure not to overload the "customer" with too much information at one time. Start small and branch out.
Enjoy!
ps. Did I miss a tool or category? Drop me a line!
Jason Rudolph is presenting his popular talk on Getting Started with Grails tonight at the RTP Java User's Group. If you're wanting to learn more about this dynamic language innovation on the Java platform, don't miss this event.
Even if you don't use Grails at your day job today, you need to understand the basic concepts. Then you'll be able to intelligently evaluate other frameworks when they come across your desk tomorrow.
It sounds like the Cobertura team has added some nice features to the 1.9 release. If you've not used a code coverage tool before, you should take a look. It's open source (so the price is right) and it'll show you exactly what your test code is (isn't) doing, which is the first step to improving your tests.
Thanks to John Lewis for letting me know about the latest release.
From the Cobertura Sourceforge page page:
We've released Cobertura 1.9! There is much improved
branch/conditional coverage and a new maxmemory attribute that can
be used if instrumentation needs more memory. See below
for the full list of changes.
-
Much improved branch/conditional coverage. Information on whether
the true as well as the false of an if statement is
collected. Also, information on the branches of a
switch statement (including the default) is collected.
(Jiří Mareš)
-
Assume Java source files are saved as UTF-8 instead of
the computer's default encoding.
-
Write all HTML and XML reports in UTF-8 instead of the
computer's default encoding (Naoki Iwami).
-
Fix a bug where the Cobertura ant tasks would not work
correctly in Microsoft Windows when Cobertura was
installed on a different drive than the drive from which
you're running ant (Srivathsan Varadarajan).
-
Added a "maxmemory" attribute to the instrument, merge
and report ant tasks (Matt Cordes).
-
Improve support for Maven and similar environments where
control over system properties is difficult such as
app servers, IoC containers, IDEs, etc. Setting the
datafile location is difficult in these environments.
To correct this, a cobertura.properties file
located in the classpath is used to properly set the
net.sourceforge.cobertura.datafile property.
(Joakim Erdfelt)
One of the good things about traveling is getting to meet people face to face that you have known from email in the past. Allan Wick and I have interacted on the Cruise Control mailing list before, but I never got to meet him until I went to the Wisconsin Java User's Group (courtesy of Northern Wisonsin Software Symposium).
He told me that he was releasing a new version the GUI configuration tool for Cruise Control. He's also done a lot to improve the docs on the project. If you haven't taken the time to try out the GUI config tool before, this would be a great time.
CruiseControl Config home page.
