JUnit is the defacto standard for Java unit testing but story doesn’t end there.
There are couple of worthy alternatives which offer couple unique features, if not everything better than Junit. There alternative frameworks for desktop & web development applications.
Well, to be on fair sides, why would you typically want to move away from Junit, what they offer the best, which Junit may not:
- Cost: Is the framework fast and easy to develop and hence low cost when compared to others?
- Efficiency: You should really be bothered about this if you run too many tests on application. Faster frameworks can really boost build times in large projects and save a lot of time.
- Integration /eExtensibility: Is it easy and possible to integrate them into the daily nightly build.
- Serving the purpose / coverage: If they are easy to write, do they really help cover the code you wish to cover?
Well, if you have those questions answered, here are the alternatives you should look for:
Selenium is bult for the web, a top-down browsers plug in and framework based on macro-like actions within a browser along with a set of assertions on those actions. E.g. Goto page A, tingle with attribute B, performa action C, expect a result D.
It mimics user behavior, focussing on important scenarios which makes sure app runs the expected way. This is the closest you can get, not only you get to do unit tests, you can lay down full plan that has vertical coverage of features.
But selenium doesn’t come without disadvantages, since it looks for attributes, its dumb and is tightly integrated with the code. http://seleniumhq.org/
Mockito is one of the easiest test framework we’ve come across. You can really get your tests up and running in matter of minutes. Overall, it reduces project cost by reducing the man hours effort required to create tests. It also reduces cost with respect to setting up databases and avoid writing your own. Its still in early stages, but most of the stuff you’ll need works well today. http://mockito.org/
JTiger is a newer framework which relies heavily on the new features in Java 1.5. Annotations and static imports are the main attractions of JTiger. JTiger requires no external configuration files to execute the tests. Setting p the project was easy and fast. I was able to write basic test and make it up and running in under 10 mins.
Like JUnit, the core of JTiger is the test cases or fixtures. JTiger tests are denoted with the @Test annotation. This annotation can take a single string for the name, or named parameters for a name and a description. However, sometimes only a certain subset of tests need to be run. JTiger provides the @Category annotation to allow for logical grouping of tests. A given test can be in multiple categories and the @Category annotation can be applied to the class definition so that all the tests on the class are in the category. These categories are invoked via a regular expression value passed to JTiger when the tests are run.
JTiger provides many different assertion capabilities.
JS Test Driver
If you love the power of annotations, this is one framework you gotta checkout. Simple annotations can add magic to your tests. This makes it easy to write the tests, and an Eclipse plug-in means that your incremental builds are incrementally tested. http://www.sureassert.com/
TestNG was built to knockout the worst of Junit. With TestNG, gone are those issues like awkwardness in the assertions, executions of batched tests, and test initialization code that only needs to be run once. Like JTiger, TestNG also takes the annotation approach for marking up tests but takes the extra step of providing a javadoc mechanism for users still on JDK 1.4.
TestNG provides a few more features beyond what JUnit provides. TestNG has a flexible test configuration system (partly through the XML configuration). It also has built-in logging, a powerful execution model and configuration, test grouping, and dependent methods.
TestNG even allows definition of chain of methods to execute before a given test case is executed. This is really helpful in various projects where lot of test code depends on dependent methods. The redundancy of failures are not listed in results. i.e. one bug will not cause all tests to be listed as failed. Saves a lot of effort trying to hunt down the root cause of all failures. This is possible via the concept of dependencies on tests: A test can depend on one or more other tests and on groups as well.