Dynamically generated Unit Tests with Ea...

Dynamically generated Unit Tests with EasyCoverage, a new Open Source framework

Posted by Romain Delamare in Scertify™ EasyCoverage on December 17, 2012 with 2 Comments

• 
  
  
  
  
• Tweet
• 
  
• 
  

• Tweet
• 
  
• 
  

Unit tests often require repetitive and tedious basic verifications. This is error-prone and not time-efficient, as the developer also need to concentrate on the logic of the classes under test. At Tocea, we have developed a tool to help developers with these simple verifications: EasyCoverage can dynamically generate unit tests.

EasyCoverage offers several benefits. It is fully automated and does not generate any source code. Test cases are generated at runtime and are only stored in memory. It is configurable and extensible. You can easily specify which classes or methods should be tested, and you can have several test suites, each with its own configuration. You can add your own checkers to improve the performed verifications.

Download it :

JAR on sourceforge

Maven central and Maven repository

POM dependencies :

Checkers

Checkers perform verification, either on a method or an a class. You can implement your own, or use some of the implemented ones. You can read the checkers documentation for more information on how to write one. Here are a quick description of the default checkers.

Class checkers

Class checkers will make verifications that are related to the class or can be done only once per class.

• BijectiveCompareToChecker
  Checkers that verifies that for any class implementing Comparable, o1.compareTo(o2) is always -o2.compareTo(o1).
• BijectiveEqualsChecker
  Checkers that verifies that, for any class implementing equals, o1.equals(o2) returns the same result as o2.equals(o1).
• CloneChecker
  Checkers that verifies that, for each class implementing Cloneable, that o.equals(o.clone).
• NPEConstructorChecker
  Checkers that verifies, for every constructor of a class, that they do not have a null pointer exception.
• NullValueEqualsChecker
  Checkers that verifies that equals does not return null, for each class implementing it.
• ToStringNotNullChecker
  Checkers that vefiries that toString does not return null, for each class that implements it.

Method checkers

Method checkers will make verifications on a method and can thus be executed several times per class.

• ArrayIndexOutOfBoundExceptionChecker
  Checkers that verifies that no array index out of bound are thrown. It will try to invoke each method with min and max values.
• GetterNotNullChecker
  Checkers that checks a getter does not return null.
• NPEMethodChecker
  Checkers that verifies that a method does not throw a null pointer exception.
• SetterChecker
  Checkers that verifies, for a getter/setter pair, that the value return by the getter is the value previously set.

@SkipAutomaticTests annotation

The @SkipAutomaticTests annotation can be attached to a class or a method. Checkers will not be run on an element with this annotation. It is useful if you want to automatically compute a list of classes (for instance wiht ClassScanner), but some of the classes should not be tested. It is also useful to skip a few methods in a class, but still test the other methods.

Quickstart

In this tutorial, we will see how to configure Easy Coverage with JUnit. First you need to configure your project to use Easy Coverage. If you are using Maven, just add dependencies to easyCoverage4J-framework and easyCoverage4J-junit (both in group com.tocea.easycoverage). Otherwise, just download easycoverage-framework.jar and easycoverage-junit.jar and put them in your classpath. Easy Coverage depends on slf4j, Logback, and of course JUnit, so be sure to include these too. Now you are ready to configure your first Easy Coverage test suite. Create a new class with a unique static method suite that returns a TestSuite:

To create a test suite you are going to use the helper class JUnitTestSuiteProvider. This class will hold the configuration of the test suite, such as the classes under test, the checkers to use, etc. Create an instance of JUnitTestSuiteProvider. The constructor has an optional String argument, which is the name given to the test suite (if no name is given, a default name is used).

There are two ways of specifying the classes under test. You can add the classes manually using JUnitTestSuiteProvider.addClass(Class<?>), or you can use the helper class ClassScanner, which can scan a folder and return a set of classes (in this case use the JUnitTestSuiteProvider.setClasses(Set<Class<?>>)method.

Now you need to specify how the instances of the classes under test will be created. Easy Coverage relies on instance providers. A default one is used if none is given. You can find more information on instance providers, and how to create your own, in the instance provider documentation. In this example we will use the default one, thus we do not need to do anything. The last configuration step is to specify the checkers to use. There are two kind of checkers, class checkers and method checkers. For more information, and a list of implemented checkers, see the checkers documentation.

You can specify on optional timeout (in ms), with the JUnitTestSuiteProvider.setTimeout(int)method. By default there is no timeout (the value is 0), but you can set one if need be (for instance if a bad configuration causes the method under test to freeze of loop indefinitely). Finally, you just need to return the test suite created by the provider:

Your method suite() should look like this:

Just launch the test suite with your favorite JUnit runner, and you will see a list of test cases dynamically created. Here is an example of JUnit report (in Eclipse) produced by running Easy Coverage on itself:

This is the coverage result (using EclEmma):

Romain Delamare (See other posts)

Romain Delamare is a research engineer at Tocea, and works on software architecture verification and software testing. He holds a PhD. in computer science from the University of Rennes and has conducted post-doctoral research at the University of Alabama. He has contributed to diverse research domains, such as software testing, model-driven engineering, or aspect-oriented programming.

2 Comments

http://tocea.comTomek Kaczanowski on December 18, 2012

“for every controllers of a class” -> “for every constructor of a class”

http://tocea.comSylvain on December 18, 2012

Thank you, We fixed. Nice web site you have!

Comments are closed.