Unit Test Helper

Working on JUnit is fun and great but always remember a golden rule "Never change a good design just to make it accessable/runnable by JUnit". Let me elaborate on this statement to tell you what exactly I meant. In our code we write data access layer, which creates connections and execute sql.

Specially in Web Application, connections are often managed inside container and are accessed by our code using JNDI. This is one of the industry best practices. Problem is how to test that code outside the Container. How to make that code JUnit accessible.

Normally we might make some changes in our code in order to make JUnit run outside container, DON'T. With the above statement I meant these kind of changes specially. But the question is what is the solution for this situation. Should you leave that code untested? No, you can still test that code. And I am not going to talk about any new testing methodology either. You can test the same code with simple JUnit.

This is made possible a small helper jar called JRUnitTestHelper from Java Ranch. This junit utility helps create JNDI based datasources and connections at the run time to assist junit test the code efficiently.

Using this jar is very very simple, put this jar in your classpath while running your junit test and call these two lines

if(JNDIUnitTestHelper.notInitialized()){

JNDIUnitTestHelper.init("jndi_unit_test_helper.properties");

}

And of course please mention your connection details like IP, port, username etc in this "jndi_unit_test_helper.properties" properties file. Please feel free to shoot me emails if you have any questions.

The jar for this program can be downloaded from JavaRanch.

Cobertura - Test Coverage Tool

Many a times we wonder that why a software failed even when we have got everything insured with unit tests. Or some times the situation are when we are not exactly sure why the software is not working the way we want it too even though all the tests are passed. If you have gone through similar situations and looking for an answer, this is it.


Cobertura is a versatile Java unit test coverage (This blog is about J2EE right) tool. It is a profilic tool that calculates line by line coverage and branch coverage along side other useful metrics like McCabe Complexity Number etc. But the most important idea is that you can see whether your tests are executing your code at each line or not. This becomes very important at the time when you are debugging the unknown error or securing your code for future moderation sensitivity. In any case nothing better than a FREE TOOL. Yes you heard me right its Free. You can download the same from here http://cobertura.sourceforge.net/. If you find any dificullty in installing the same for your project, feel free to write to me.


If you are an advance user and already knows about cobertura than there are chances that you probably might also knows about Clover (Paid Tool Not Good ) http://www.atlassian.com/software/clover. Price is very high but the dashboard they provide is execellent.


So don't be disappointed if you cannot purchase the same, as in the near future I will be updating my own xsl sheet which can generate similar report for you without fuss. And yes that will be absolutely FREE, you can donate some bugs for my beer if you wish. But that xsl is free no questions asked :)


By the way, this is what Cobertura reports looks like this:

While my xsl will process the output and provide a report like this:

Watij - Web Application Testing in Java

WATIJ stands for 'Web Application Testing in Java'. J2EE deals with creating Web Applications, and like in most cases project teams cannot afford dedicated testers due to "resource limitations", "schedule limitation", "management limitations" and for many other unique explanations and reasons. In some cases where they even do hire manual testers, the job of the tester becomes tedious since most of the team nowadays follows Iterative development model like AGILE, Spiral etc. And thus they need to repeat testing for same set of functionality with every release to ensure that 'new' has not broken 'previous'. And thus with every release the burden on the poor fellow only keeps on getting tougher. Like many other web application, one very important but common feature is Authentication & Authorization. Authentication stands for identifying the users while Authorization refers to validating user's rights within the system. For all these functionalities the tester has to check every time with every release whether they are intact or not. THIS CAN BE AUTOMATED and thus bringing hours of testing effort to be reduced to minutes of self automated runs.

Now, I know that you know that it can be automated using costly tools like QTP etc. But what I am telling you is that it can be done free of cost using a Open Source tool name as WATIJ. Watij is built over JUnit and thus provides similar interfaces to write the tests. But writing tests are very very simple, when I say simple it means so simple that even my QC and QA who doesn't had previous experience on Java where able to write hundreds of tests. The (wiki) site provides easy tutorials to start with and I am sure you will love it when you start using it.

But there is a catch, as there are few limitations to the tool at the moment.

1. Currently it only works with IE
2. It doesn't works with Applet (Huh, like any body is using it nowadays).

I tried it with AJAX and it gave good response on many occasions but not sure if it can support advance javascript functionalities like "Drag and Drop" etc. But with all the features it has, mind you it is worth trying.

There exists NO Alternative 4 Unit Testing

There exists no alternative known for Unit Testing, although there exists '∞' number of tools which can help you in doing it. Since this blog is oriented towards J2EE, I will talk about JUnit. A tool that has revolutionize the way code is developed (Are you wondering why I didn't said "revolutionize Testing"? Its because its not helpful for tester, it is more helpful for developers). It truly is, it helps developers to eliminate bugs in initial stages. Sach ("Really"), It has been proved over and over again. People, Thinkers, Great mind have always stressed on its usage but we never listened. Let me try to put up the same in another way which may persuade you to think otherwise.

Lets say, you are building a house (Please start thinking about your dream house which you might have wanted to build or have build already). Now lets start with a land, you will have to buy a land somewhere. Everybody have some choices, specific opinions, lets say some people want their home to be situated in a good colony, some might want it to be far away from city rush. What ever is your choice, tell me would you evaluate the prospect land before buying or after buying? What will happen if you find out after completing your house that the land is not fulfilling your all choices? Either you redo the cycle again (which I am sure most of us here cannot afford to do) or stay with a compromise.

Lesson 1: Please start testing each unit unit of code before you complete your software. DONOT put off testing until completion, as either it will leave you with a compromise or will require you to do the whole cycle again. You choose, for me choice is simple. :)

Now, why unit testing is better. I am sure you will be very familiar with the term unit. You use it quite often in your daily life, its a measurement terminology. For e.g. you buy milk 1 litre/day. Litre is your unit to measure the milk quantity. What is the unit for software? Milk quantity can be measured in terms of Litre, Kilo Litre, may be in ounce or kg. There can be many unit to measure the same product. Same way in software you can use NCSS (Non Commenting Source Code) as your unit or function as your unit. In case of JUnit normally function is treated as one unit and test can be written to test each functions.


Now, lets say you have assigned construction of your house to a vendor (may be due to time shortage). Will you make visits to your house frequently or let the constructor build the complete house and than you will go for inspection. The answer is pretty straight forward, frequent visits will allow you to check the progress made which will result in better control on the construction. That means you can check each "unit" added daily and thus perform better quality control. Same way, if in software construction as well, it will be far easy to write tests for each unit and test it seperately instead of testing software as a bundle (whole).