Swarm of XeBees

Nowadays when Agile is on its peak and Junit tests hijack the technical discussions. Its very easy to find people obsessed with Junits. You can really sense the excitement in people when they talk about Junits.

I consider this as one of the major achievements of the Agile promoters. They have been really successful in transfusing Junits in the blood of developers, managers and even clients. Generally, I see questions in demo regarding the code coverage. And then, I see the team writing Junits, one after the other, to set the Junit coverage above the expectations of the client.

However, most of the people, who are into this highly geeky practice of writing Junit tests, really write Junits which are even worth a penny?

If we do a voting for the reasons of writing Junits, and developers are allowed to vote without their manager or client watching them, I am pretty sure that “Increasing Code Coverage” is what will emerge as the clear winner. And I do not blame developers for it.

The manager or the client, who pushed them to write Junits is the real culprit. Regarding the manager, I will say, that he rarely sees the code, or never sees it. But, he wants a good coverage to show to the client. Its business.

All, the client generally knows about the code is the statistics generated by various tools. So, the only thing he bothers about, is the code coverage. And I do not blame the clients for this expectation. Because this is what the Agile coach told them. This is what he knows. “All the code should be covered with Junit tests”. And then you will gain eternity. Huh.

Just a thought, if everyone will keep talking about the code coverage and Junit tests, then who will talk about the code. Basically, the focus has shifted to write Junit tests which tests the code, rather than the actual code.

The developer keeps on writing code, ifs, elses, switches, methods after methods. The class size grows upto 1000-2000 lines long. But, the code is covered with Junit tests. And when you will see the Junit tests, it will scare you.

The Junit tests for large classes are 100-200 lines long. Whenever someone will write some code, he will add another two lines in Junit test also, So that the test can pass and the code executes. No matter what the Junit test is testing. Sometimes, Junit tests become so hard to modify, that people comment out the assertion, so that the test can pass and they can commit the code into repository.
Will we get any benefit from this type of Junit tests or coverage which these Junits show? NO.

We need Junit tests to make sure the code is doing what we expect it to do. But if the Junit itself has become too complex, how can we use it for any such purpose. Its no more simple and understandable.

Moreover, these complex and long Junit tests sometimes become bottleneck in development. You changed something and you need to fix the complex Junit test covering it. The time taken in making Junit tests pass is sometimes much more than what would have been taken to write a Junit test from scratch. And since you or your peer has spent days writing the Junit, you do not want to delete it. Because its so close to your heart. You invested so much time in writing it. Bullshit.

My suggestion is, the time you see a Junit test which you can not understand, delete it and rewrite it. In most of these cases, the class, the Junit test was covering would need refactoring. See whether the class is doing too much. If its doing a hell lot of job, break it into simple pieces. And write simple and logical Junits for them. If you have existing Junit test cases, it will help as a safety net while refactoring. The tests will ensure that the refactored code does not breaks the functionality ( if the existing Junit tests were not rotten).

But what if you need to refactor classes which have no existing Junits?? People will say, that, never ever refactor a code which is not covered by Junit tests. Because Junit tests is a safety net around which you refactor. So, does this means that you should write Junit tests first for the complex classes and then refactor?

NO. Simply NO. Until and unless there is nothing else to do in the project or you really want to make your life hell. In short, until you have lots of time.

Writing junits for pre existing complex classes will not be that easy. It will take hell lot of a time. Also, the tests will not make any sense, as they will be too complex to understand and maintain. The Junits lose their sanity after the class being tested breaches a complexity level. And if you have really less time, then try to write Junit tests for classes which get changed really frequently. Junit test around a class you know is never going to change is useless. Always have tests around classes which change frequently.

So, just try to do some initial safe and easy refactoring first. So that you can add some basic junits. And then use these junits to refactor the code mercilessly to its simplest form. The refactored code, broken into simple understandable pieces will have the logical junits which will make sense.

If you have a tool which shows the statistics about the project in timeline, the complexity should decrease gradually, when you refactor, along with increase in the code coverage.

So, shed the obsession with Junit tests. Start writing “Clean Junit Tests”.

Filed under: Extreme Programming, Java, TDD