Unitee Testing Framework

Development

Overview

What Unitee stands for? Unitee is a combination of
* Unit - for unit testing , and twists of
* Unity - for united set of tests , for all sorts of levels (unit , system , etc.) , and
* Tea - on the weight of Java

Why Java?
Java was the major target platform because:
* It was the main development language I worked with in the last years
* Java classes could be most easily loaded on the fly (although COM could too , and C/C++ code *could* be created with some overhead)
* Java is the language Unitee is best implemented with.

Why Unitee? or: Requirements , Features
Major requirements for Unitee:
* Test cases are as simple as possible
* Test cases require as little knowledge of the Unitee framework as possible
* Test cases could be configured with different test parameters (e.g. values are not hard coded in the test)
* Test cases can test they have all parameters they need
* Extensible framework - Unitee can be extended , for example , to test COM components.

And by that provide a replacement for the overly complex and rigid JUnit.

Strategy

Talking about the 3 other kinds of testing besides unit , may have got you thinking: who the hell is doing those? Usualy those are the developers themselves , but sometimes its the folks from QA. Unitee is aimed to provide their needs too. Version 1.0.0 is stable , but Unitee requires more work to make it usable by developers who need GUIs , and QA people.

Building around the stabilized base framework of unitee , applications (GUIs) can now emerge , while using the existing minimum (UniteeClient).

Vision

The process of testing a software component could be difficult enough , so adding more difficulties will result in the opposite effect. Examples: A TestCase implementor
* have more trouble to create test cases of his/her own (e.g a programs with a main())
* have more code to write and debug if using JUnit
* have a lot of trouble passing parameters around
* cannot reuse tests

Therefore , the TestCase implementor would be motivated to use the framework in order to:
* write less code , especialy when testing for different parameters is required
* debug less user written code , and debug no framework code

Here is the hello world test case:

 
public class HelloWorldTest implements TestCase {
    public void init(TestParameters params) throws ParameterException {}

    public void test(PrintStream output) throws Throwable {
        output.println("Hello world!");
        }
   }

public class MyTest implements TestCase {
    private String stringParam;

    public void init(TestParameters params) throws ParameterException {
        stringParam = params.getString("myParameterName");
        }

    public void test(PrintStream output) throws Throwable {
        MyComponent mc = new MyComponent();
        output.println("mc.method1() returned:"+mc.method1());
        }
   }
 

public abstract class MyTest implements TestCase {
    private String stringParam;
    private long longParam;

    public void init(TestParameters params) throws ParameterException {
        stringParam = params.getString("myParameterName");
        longParam = params.getLong("myLongParam");
        }

    public void test(PrintStream output) throws Throwable {
        // the logic for building and initializing the component is here...
        MyComponent mc = new MyComponent(stringParam);
        mc.callAnotherMethod(longParam);

        test(mc , output);
        }

    public abstract void test(MyComponent mc , PrintStream output) throws Throwable;
    }
 

public class MyMethod1Test extends MyTest {
    public void test(MyComponent mc , PrintStream output) throws Throwable {
        // do some more initializations , and finally:
        mc.method1();
        }
    }

Every exception thrown by the tested component or the test case component will propogate into the framework that will realize that the test has failed.

Versions

Licensing

Status

Todo

Download

You will also need Sun's XML parser code that is provided here for your convenience , and is usually provided as part of the JSWDK package , in a file named xml.jar. See http://java.sun.com/products/servlet/download.html. You will have to add this JAR file to your classpath , or to specify it as part of the java command.

API Documentation

Running

Overview

root
  application/framework tests
    subsystem/package tests
      class tests
        method tests

Issue the command:

java unitee.client.UniteeClient <Parameters...>

alias unitee='java unitee.client.UniteeClient'

Adding A Suite

unitee -s hello root

Adding A Test Case

unitee -c SimpleHello test.unitee.HelloWorldTest root/hello

Printing the Test Tree

unitee --tree

TestSuite root
   TestSuite hello
      TestCase "SimpleHello"
         class: test.unitee.HelloWorldTest
   end of TestSuite.
end of TestSuite.

Running a Test

unitee root/hello/SimpleHello

STARTING TEST "root/hello/SimpleHello"
Hello world!
TEST "root/hello/SimpleHello" has finished successfuly,
Time: 2
Test summary:
root/hello/SimpleHello succeeded.

Parameterized Tests (Test Data)

unitee -p -c Parameterized test.unitee.ParameterizedTest root/hello

choose action (a - add,r - remove,e - edit,q - quit): a
parameter name: longParam
parameter's class: ENTER
possible classes are l - long, d - double, s - String, b - byte[], p - password
parameter's class: l
parameter's value: 58
choose action (a - add,r - remove,e - edit,q - quit): q

public class ParameterizedTest implements TestCase {
    long longParam;
    String stringParam;

    public void init(TestParameters params) throws ParameterException {
        longParam = params.getLong("longParam");
        stringParam = params.getString("myString");
        }

    public void test(PrintStream output) throws Throwable {
        output.println("the long value is:"+longParam);
        output.println("the string is:"+stringParam);
        }
    }

TestSuite root
   TestSuite hello
      TestCase "SimpleHello"
      class: test.unitee.HelloWorldTest
      TestCase "Parameterized"
      class: test.unitee.ParameterizedTest
         long parameter "longParam": 58
   end of TestSuite.
end of TestSuite.

unitee root/hello/Parameterized
missing parameter "myString" of type String

unitee -p root/hello/Parameterized

choose action (a - add,r - remove,e - edit,q - quit): a
parameter name: myString
parameter's class: s
parameter's value: blah blah blah
choose action (a - add,r - remove,e - edit,q - quit): q

STARTING TEST "root/hello/Parameterized"
the long value is:58
the string is:blah blah blah
TEST "root/hello/Parameterized" has finished successfuly,
Time: 4
Test summary:
root/hello/Parameterized succeeded.

So , in the example above , if all test cases under "hello" suite needed the parameter "helloParameter" , we could have added it by using:

unitee -p root/hello

choose action (a - add,r - remove,e - edit,q - quit): a
parameter name: helloParameter
parameter's class: s
parameter's value: my hello string
choose action (a - add,r - remove,e - edit,q - quit): a

Unitee server

java unitee.server.UniteeServer

Clients can connect to that server by adding "--server <server-ip-addr>" to each command:

unitee -p root/hello/Parameterized --server localhost