Any tool is a weapon if you hold it right

My technical team lead recently made the mistake of asking for feedback regarding the last release of our project. Well, I decided to raise the issues (and some suggestions) that I have been talking to individuals about for a while – particularly w.r.t the poor quality of the codebase and unit tests. This has resulted in my become part of a new “quick-win” QA initiative to improve the codebase and code that is added to it from now on.

So, I have two main tasks to complete over the next week or so: one is create an ANT script that developers can run over the codebase before they check in (checkstyle, compile, JUnit, etc. – currently they only use Websphere builds and CruiseControl); the other is to prepare and deliver a presentation on how to write tests that are UNIT tests, mock objects, code that is easier to test, etc. I know I’m not an expert on this stuff but I hope I can do the topics justice and get some good results.

Anyway, my point: I had to think of a way to run Checkstyle over the codebase without having the developers ignore the 50000+ errors (no, that’s not an exaggeration). So, I developed a custom selector that only selects the writable (and therefore, checked out) files to check. That way, they have to fix Checkstyle errors on checked out code before they check in.Handy tool #1. (PS. I’m trying to convince them to let me change the Checkstyle settings to focus more on coding problems rather than enforcing Javadoc for every single thing – cause people don’t fill out the bloody templates anyway! – and other style issues that will take a long time to fix for the whole codebase.)

I also had to think of a way of easily compiling the codebase (there are major dependencies!) and nicely displaying the compile errors – oh and the WSAD ANT task for building is not very helpful. So, I developed an ANT task that calls the already configured WSAD workspace build and displays compile errors that link to the source file. Handy tool #2.

I also wanted a way to easily show developers what files they may have forgotten to check in / add to source control. Now, I know that’s easy in something like WinCVS and it’s doable in other tools but we are using PVCS and it’s sloooooow and it doesn’t show files that haven’t been added to it’s control. So, I developed a custom ANT task that uses a fileset (to include / exclude file patterns) and displays a list of all files that are not read-only (a borrowed idea from a colleague who wrote his own command-line tool to do the same). Handy tool #3.

So I hope these tool ideas help to encourage everyone to check in better code. Of course it’s not a silver bullet but I think most of them would be happy to have better development procedures and a cleaner code-base; after all every one on the team has had to fix bugs at least when they started. And hey, if you find yourself in a similar sort of environment / situation, feel free to steal these ideas – of course they’re nothing miraculous.

So now I’m looking forward to rolling the new build file out next week when I am let loose to lecture the developers…. mwahahahahaha.

PS: A good tool I found (actually a WSAD plugin) – for showing coding problems, cyclomatic dependencies etc.: Metrics

Another tool I’ve discovered – a decorator for JUnit tests that fails the test if you have not tested every branch of a class (sort of on-they-fly test coverage checker). Good for TDD and really easy to use: Hansel. 

• A whole new world
• Dave Astels: One Assertion Per Test