There have probably been a few rants on this log about bad unit testing. If not, then this one ought to cover all of the bases.

I write software. Currently I'm writing J2EE software (enterprise level web-services in Java, for those that don't like acronyms). One powerful tool that a lot of places like to employ, and for a variety of reasons I'm on board with, is JUnit testing of Java code.

For the uninitiated, a JUnit test is a little snippet of software that will (when done correctly) automate the process of testing parts of software. When done correctly, the tests will prepare a situation, call the method being tested, and validate the proper changes have been made.

Used thoroughly, JUnit tests can greatly enhance the confidence in the quality of the code. In addition to making sure that the software acts predictably (as the tests are repeatedly run), it helps defend the software against unwanted changes. If a developer changes a method that has proper tests written against it, the existing tests should fail. This is a good thing; it alerts the developer that there's a reason for the code to have been the way it was. The developer can then either correct the test to reflect the change in design, or revert the method and come up with a different solution to the problem at hand. Either way, when done, there should be a test validating and ensuring that code's integrity.

With proper test integration, all of the software written for a project will be covered with tests. In a good environment, in fact, several tests could hit the same method; a test with a good set of values (or more than one), and tests with values that can cause failures, proving that the method handles failures as desired. With this idea that (arguably) the same software will have to be written multiple times when using tests, and many developers shun the practice.

Additionally, there's a part of science and a part of art to writing software in general. Some developers are stretched enough just getting simple code out of their fingers. Give them the extra task of writing good cases and bad cases against a simple method, and they rebel.

What has started this rant is that I've recently been tasked to do a little proof of concept with another group's code. I started the proof with our code, and made it work, but the greater target is this other group's code. In our code, I learned about the deal they're trying to plug in and discovered the least impact necessary to implement the deal.

Then I turned to the other project.

I made the simple changes and verified that everything built in the IDE. Excellent, fast, easy, and as I had documented with no changes. I then tried to run their automated build and tests. Their build and test script didn't work.

I thought to run the tests then in the IDE, just for a baseline, but discovered that they didn't even include the test folder in the IDE source folder configuration! This means that while the files did exist on the drive, they were not visible to the IDE, so the code was not compiled and verified even to that simple level. Certainly they weren't able to be executed. A simple change of the build path and they were in (no compile errors but hundreds of warnings), but they didn't run.

I was parallel tasked with correcting their Ant build script. I've spent the better part of today making the build work, and now I'm starting to work on getting the tests to run. At this point I don't care if they PASS, they just need to RUN.

Now it's looking like the task is going to bleed into tomorrow, so I'm gonna cut for the day...I'll rant more and maybe offer some how-to suggestions to get started on unit testing.