-k.

I’ve spent the last eighteen months working on a large java project for one of Australia’s largest companies. The project is split into three primary streams. The server, the client and legacy data migration.

My team has been responsible for the server side of the application. We are responsible for storing several terra bytes of structured and unstructured information and providing access for hundreds of concurrent users. It’s been a challenge (and there are still some aspects that we need to do better), but we have generally been able to stick to our deadlines, so has the team doing the legacy migration. Unfortunately the team doing the client application has not been able to deliver, so a little over two weeks ago I was moved over to lead the team. What a mess.

The code has more issues than a schizophrenic ax murderer and more bugs than a Louisiana swamp. It’s riddled with insanity, how they got this far I have no idea. As an example at some point someone decided that it would be a good idea to provide application level events. Something happens you blast of an event and those that are interested get notified. Not all that insane you say, well they didn’t stop there. No you see they now had a framework. The next bright spark decided, “well if it’s good for notifications, hell it’ll be great for requests.” So now when you want to call a method on a service you send an event. The service executes the event and calls back to the listener attached to the event to inform it what has occurred, sometimes. Other times the request triggers a broadcast of the result so the caller needs to be able to listen for these general announcements. Then of course there is the routing of the message, oh, the routing. Half a dozen proxies and several thread later you request is made. Needless to say debugging event execution is very difficult. So another bright spark decided, “well hell, his is all a bit hard and all this asynchronous processing and threads make my head spin how about we allow you to just send the event synchronously?” So now the services (many of which aren’t inherently thread-safe) are being called from a number of different threads. Of course to make unit tests easier to write and understand the system switches to an entirely different mode of operation.

When I took over there were java files with over five and a half thousand lines of code. Large numbers of of classes that no one knew the function of and a runtime dependency on junit. Every developer either blamed another for the state of the code or had decided that they would just ignore the world around them and spot fix their own little patch of grass. The combined effect was that the application was collapsing in on itself. Bugs would appear then disappear. There was no realistic chance that the application would ever be delivered in a usable fashion to the business.

There are no really bad developers in the team. They have just not delivered on their talent. Now I have to deliver the application. Things are changing. Attitudes are changing. It’s a real challenge given the timelines. It’s a lot more work than it looked like from the outside. It’s going to be fun. I just hope that I have some friends when I finish.

After spending some time playing with the latest version of TestNG I’ve decided to begin the switch from JUnit. TestNG is an evolutionary step forward in unit testing for Java. For me a big advantage is that it makes it much easier to group my tests. Right now I use separate test directories which, although functional, is at times a pain in the ass, TestNG allows me to group using annotations. Setup is also a hell of a lot easier. I can choose if a method executes before each test or just once for the test class which makes expensive operations such as managing database connections easier to manage. The other bonus is test dependencies. I know, I know, there is the whole “tests should be independent argument”, but what is the point of testing operations on a connection if the test to create that connection fails?

To be honest the reason I’ve waited until now to switch has been the lack of IDE support for TestNG. That changed a couple of weeks ago when Cédric announced the TestNG Eclipse plug-in making it trivial to use TestNG directly from eclipse. I’m not changing everything over night (I have hundreds of test classes). New test classes are now written in TestNG and if I need to go back and extend or resolve an issue in a current test class I update it to TestNG. My old tests are run using TestNGs JUnit compatibility mode so that I get a single report for all my tests.

TestNG comes with a lot of documentation. For a shorter introduction I recommend you read TestNG makes Java unit testing a breeze.