Expertiza documentation
Plenty of Testing framework exist for Java. JUnit has been the de facto standard for unit testing. However, other frameworks such as TestNG, JTIGER have been built to address various faults and deficiencies with JUnit. Our primary objective is to compare the various testing frameworks that exist for object oriented languages based on the primary purpose of the framework, strength, platforms that are supported by them, etc and thus help in choosing the best testing framework that fits in a particular suitable environment.
TestNG is a testing framework which can help to meet a broad range of testing such as unit testing, integration testing, functional testing, end-to -end testing.
To write a TESTNG test, we need to: Write the business logic of the test, and insert the TestNG annotations in them. Add the information about our test (such as: the class name, the groups we wish to run, etc) in a testing.xml file or in build.xml. Run the test. TestNG supports data driven testing
TestNG is invoked in several different ways: With a testing.xml file ANT Command line
It is possible to group the test methods of TestNG. We can declare methods that belong to these groups and specify groups that contain other groups. It is very flexible as it can help in choosing one set of regular expression and excluding the other sets. This splits the various test groups and there is no need to recompile again if we want to run two different tests back to back.
Requirements: JDK 1.4, 1.5 Invoked in many environments such as command line, ant, ECLIPSE, IDEA, MAVEN, etc
The annotations available in TestNG can be found at: http://testng.org/doc/documentation-main.html#annotations
TestNG is inspired from JUnit and Nunit, with additional functionalities such as Flexible test configuration, support for data driven testing, etc.
' | JUnit4 | TestNG | Cactus |
Supporting Type of Testing | Suitable more for Unit testing | Supports Unit testing,Functional testing, end-to-end testing, integration testing | Primarily unit testing. Also have frameworks for code logic unit testing , functional logic unit testing |
Conventions | Rigid Example: | Flexible | Not as flexible as TestNG |
Derived from JUnit | Yes, from the previous versions | Inspired from Junit,with added functionalities | Extends JUnit |
Init () | Init() has to be declared static | Not necessary | |
Flexibility for large suites | Not flexible for large test suites, | Flexible for running large test suites of code and thus one test\'s failure shouldn\'t mean having to rerun a suite of thousands. | No, it is suitable for unit testing. |
Suitable for | Best for a single object | Best for a higher level testing | Best for server-side java code such as Servlets, EJB, etc. |
Runs on | Command line, ANT,ECLIPSE | Command line,ANT, ECLIPSE, IDEA,MAVEN | ECLIPSE |
Comparison between JUNIT 4 and TestNG
JUnit 4 v/s TestNG
(source: http://www.ibm.com/developerworks/java/library/j-cq08296/)
The frameworks differ is in their core design. JUnit has always been an effective unit-testing framework, meaning that it was built to facilitate testing single objects. TestNG, on the other hand, was built to address testing at higher levels, and consequently, has some features not available in JUnit
JUnit 4 makes clever use of annotations. JUnit no longer requires you to define a test as a method whose name starts with test, and we can now run fixtures just once as opposed to for each test. However TestNG established itself as an annotations-based framework long before Junit 4. TestNG pioneered testing with annotations in Java programming, which made it a formidable alternative to JUnit.
Sample J Unit 4 code
package test.com.acme.dona.dep; import static org.junit.Assert.assertEquals; import static org.junit.Assert.assertNotNull; import org.junit.BeforeClass; import org.junit.Test; public class DependencyFinderTest { private static DependencyFinder finder; @BeforeClass public static void init() throws Exception { finder = new DependencyFinder(); } @Test public void verifyDependencies() throws Exception { String targetClss = "test.com.acme.dona.dep.DependencyFind"; Filter[] filtr = new Filter[] { new RegexPackageFilter("java|junit|org")}; Dependency[] deps = finder.findDependencies(targetClss, filtr); assertNotNull("deps was null", deps); assertEquals("should be 5 large", 5, deps.length); }
} source: http://www.ibm.com/developerworks/java/library/j-cq08296/
Sample TestNG code
TestNG
package test.com.acme.dona.dep; import static org.testng.Assert.assertEquals; import static org.testng.Assert.assertNotNull; import org.testng.annotations.BeforeClass; import org.testng.annotations.Configuration; import org.testng.annotations.Test; public class DependencyFinderTest { private DependencyFinder finder; @BeforeClass private void init(){ this.finder = new DependencyFinder(); } @Test public void verifyDependencies() throws Exception { String targetClss = "test.com.acme.dona.dep.DependencyFind"; Filter[] filtr = new Filter[] { new RegexPackageFilter("java|junit|org")}; Dependency[] deps = finder.findDependencies(targetClss, filtr); assertNotNull(deps, "deps was null" ); assertEquals(5, deps.length, "should be 5 large"); } }
Testing frameworks for C++
When it comes to unit testing in Java, a unanimous choice would be JUnit. However for C++, there is no one clear winner. CppUnit is the most widely used tool for C++ which is a part of the XUnit family.
Following is a few basic factors to judge a good testing unit in C++ :
CppUnit passes most of the above tests , except for the first point and thus needs a lot of code typing. Boost.Test isn’t exclusively a unit-testing framework, and is not X Unit based.
Some other JAVA testing units
' | JEasyTest | J2ME Unit Testing Toolkit | Jailer | Mockrunner |
Features | Generates coverage report Allows virtual mock object | Is a Java 2 Micro Edition (J2ME) library containing a unit testing framework for J2ME | Does test data exporting. JDBC agnostic Generates DbUnit datasets, hierarchically structured XML, and topologically sorted SQL-DML. | A lightweight framework for unit testing applications in the J2EE environment. |
Integrates with: | ECLIPSE 3.3 | ANT | Platform Independent | OS independent |
Cactus
(source : http://jakarta.apache.org/cactus/index.html) Cactus is a test framework for testing server-side java code such as Servlets, EJB, etc. It extends J Unit. Cactus implements an in-container strategy which means that tests are executed inside the container. The Cactus testing unit can be viewed as a system that consists of the following components: Cactus Framework: This provides the API to write Cactus tests. Cactus Integration Modules: They are front ends and frameworks that provide easy ways of using the Cactus Framework. Eg: Eclipse plugin Cactus Samples: They demonstrate how to write Cactus tests and how to use a few Integration Modules.
A useful testing framework provided by Cactus is integration unit testing( type 2). The tests written for this framework will exercise the interactions with the container. Cactus also provides other frameworks such as code logic unit testing (type 1) ,functional unit testing( type 3).
Cactus was developed to fit Type 2 but also to be a very good compromise for types 1 and 3, with the idea that it is much easier to have to write tests for a single framework than for several. It is believed that Cactus provides a middle ground that provides a high confidence that your code will run when deployed .
To know how it works, click here : http://jakarta.apache.org/cactus/how_it_works.html
Testing units for C++
When it comes to unit testing in Java, a unanimous choice would be JUnit. However for C++, there is no one clear winner. CppUnit is the most widely used tool for C++ which is a part of the XUnit family.
Following is a few basic factors to judge a good testing unit in C++ :
Features | CppUnit | BOOST.test | CxxUnit |
Minimal amount of work needed to add new tests | No, and thus a major downfall. | Yes | Yes, very good. |
Easy to modify and port | Medium | Medium | Simplest |
Supports setup/teardown steps | Yes | Best | |
Handles exceptions and crashes well. | Yes | Yes, above others | Great support. |
Good assert functionality. | Pretty decent. | Yes | Best |
Supports different outputs. | Yes. Comes with IDE friendly output. | Probably, Not trivial to change. | Yes |
Supports suites | Yes. | Yes, but with a big catch. | Yes |
CppUnit passes most of the above tests , except for the first point and thus needs a lot of code typing.
Boost.Test isn’t exclusively a unit-testing framework, and is not X Unit based.
Out of the above three , cxxUnit turns out to be a favourite.
It comes close to the requirements of an ideal framework by leveraging the power of an external scripting language. It provides some nifty advanced features and great assert functionality. It does require the use of a scripting language as part of the build process, so those uncomfortable with that requirement, might want to look at one of the other two frameworks.
For work restricted to the PC, where modifying the framework is not required Boost.Test could be a very good choice. CppUnit , which has come a long way in years is a solid, complete framework The major drawbacks are the relative verbosity for adding new tests and fixtures.
http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle