Why a new testing framework?

Yes, because there is a need for a simple and easy to use java testing framework with in container testing capabilities

To be able to properly test distributed applications, developers must get each test to be executed in an environment identical to the targeted production environment(s). This technique is called in container testing and it is the only way one can achieve a reasonable level of confidence in the tested code. To be efficient, test writers should concentrate on the test logic, not on details such as test distribution mechanisms. The solution is a testing framework that would automatically distribute test case instances for execution in the appropriate container(s). All developers should have to do is mark test case classes with marker interfaces or jdk1.5 annotations to indicate in which environment / container ­ EJB, SERVLET, etc - the test must be executed. The testing framework would detect these markers, execute the test case instance in the right container and collect the results. It shall be possible to decorate a test case with more then one interface or annotation. In this case the testing framework would execute the test in each configured container.

For example, if at production time the same code fragment can be executed in an EJB container, a CORBA ORB or a RMI server, test writers should write the test only once, and decorate it to describe these environments. The testing framework would then detect these annotations and execute the test in each container.

Currently, I'm not aware of any publicly available testing framework that offers enough flexibility to fit complex distributed in container testing requirements. After hacking into JUNIT for a while, I decided to create a new testing framework designed from scratch to be:

  1. flexible enough to adapt to a wide variety of testing techniques, with native support for test decorators such as fixtures, global fixtures, environment probes and guards,

  2. distributable, in order to be able to execute test cases and decorations across a many of execution environments,

  3. easy to extend in order to adapt to a variety of execution environments and containers: client JVM and EJB containers are supported by default and it is very easy to add support for SERVLETS, RMI, JMS, CORBA ORB or web service containers,

  4. easy to integrate with existing automated test procedures and with development tools such as ant, IntelliJ IDEA and Eclipse,

  5. provide comprehensive, extensible reporting facilities,

  6. and most important, simple enough for developers to adopt it