Annotating Your Classes

You can simply mark a method with the @Tested annotation to indicate that it should be tested.

Let's take a look at an easy example:


    package org.mycompany.myproject.services;

    public class MyService {
        ...
        @Tested
        public void performAction() {
            ...
        }
    }

We shall refer to this as the System Under Test (SUT) for the duration of this tutorial. JTestConnect uses the jtestconnect.xml configuration file specified in your Ant task to determine how the test for this method should look. Lets take another look at the one we used in our example.

<!-- Configures JTestConnect -->
<jtestconnect>

	<defaults>
		<property name="package" value=""/>
		<property name="classPrefix" value=""/>
		<property name="classSuffix" value="Test"/>
		<property name="methodPrefix" value="test"/>
		<property name="methodSuffix" value=""/>
	</defaults>
	
</jtestconnect>

This file defines a naming convention that describes how we name our tests. JTestConnect uses this files to generate expected test names. Let examine what each of these values actually mean:

package - The package name that will be appended to the end of the SUTs package name to find the expected package name. In our config file we have left it blank, which means that our test class should have the same package name as our SUT. This is recommended as a best practice because it allows your test access to protected and default methods in your SUT. If we had specified "test" as the package property, we would have to put our test into the package "org.mycompany.myproject.services.test".
classPrefix - The prefix that should be appended to your SUT class name to arrive at the test class name. In this case we append nothing (we prefer a suffix). If we had specified classPrefix to be "test" then JTestConnect expects a class with the name "TestMyService".
classSuffix - The same as the classPrefix option, but allows a suffix to be added to the end of the test class to arrive at the test class name. In our example this is exactly what we have done. We will expect a test class with the name "MyServiceTest".
methodPrefix - Appends a prefix to the name of the method being tested. In our example we would expect a method with name "testPerformAction".
methodSuffix - As above, except adds a suffix to the end of the method name.

With this information, JTestConnect will determine that we need a test class called: "MyServiceTest" with a method "testPerformAction". If this method is not found in your test code, JTestConnect will complain.

Testing Everything

If most of the methods in a SUT need to be tested, then we can add @Tested to the class instead.

    package org.mycompany.myproject.services;

    @Tested
    public class MyService {
        ...
        public void performActionA() {
            ...
        }

        public void performActionB() {
            ...
        }
    }

JTestConnect will generate test requirements for all the methods in the class. We still don't want to test all our getters and setters, so we can annotate those with "@NotTested" and they will be excluded from the requirements generation.

Multiple Tests For One Method

Sometimes, one test just ain't enough. For particularly important code we may require that multiple conditions be tested. Maybe a particular validation case needs to be tested, or perhaps we need to ensure that a method fails gracefully when an error occurs.

To create multiple requirements for a single method you can do the following:


    package org.mycompany.myproject.services;

    public class MyService {
        ...
        @Tested(tests={"positiveTest", "negativeTest"})
        public void veryImportantAction() {
            ...
        }
    }

This will generate 2 test requirements for this method. The method name prefixes and suffixes are not used to find the test method name in this case (as the name has been explicitly defined).

Sometimes, when you have rather a lot of tests, you may wish to put them into different test classes. This can be specified as follows:


    package org.mycompany.myproject.services;

    public class MyService {
        ...
        @Tested(testClass=org.mycompany.myproject.services.MyServiceTests1)
        public void myMethod1() {
            ...
        }

        @Tested(testClass=org.mycompany.myproject.services.MyServiceTests2)
        public void myMethod2() {
            ...
        }
    }

This also helps when working with tests that are in classes that simply don't correspond to the naming convention and where it is inconvenient to rename the test class.

That's it for now! Hopefully more features are on their way :-)