Automate Your Integration Tests

Software testing traditionally has been separated between unit testing – testing classes in isolation – and integration testing – testing across all layers. Whereas unit testing is the domain of developers, integration testing is the domain of analysts. Moreover, most of the time, those tests are not automated and are painfully reexecuted by hand each time they are needed. This means that your build process has a safeguard harness on the unit level but nothing on the feature level (at least nothing remotely automated).

In order to further streamline the build process, it would be order to also automate integration tests. I already have some successful experience with integration testing with batches. Batches are very simple to test in this way since they lack a very hard-to-test feature, namely GUI. I developed those tests with the TestNG framework, mainly because TestNG provides the way to order test methods.

Yet, those tests I was pleased with lack one essential feature: the analyst point-of-view. It’s me, as developer, that created them and as such, they may not adress the uses cases deemed critical to the business.

What’s essential is what lies between the description of the tested use cases in plain text and their implementations in Java. My TestNG tests were developed by the developer, for the developer, in Java and couldn’t be read by a typical business analyst. At the time, it was the best I could do but a thread inside my head longed to bridge the gap between developer and analyst points of view. Luckily, I have found (at least I think) the right tool in order to solve this.

This tool is JBehave, and as you can guess from its name, it advocates for Behaviour Driven Development. Its strongest point is that the business analyst is a the root of the process. Given a few simple rules, he can describe use cases in plain language. Then, the developer ties these stories, as they are called in JBehave, into the code. There are only a few rules for these descriptions:

• describe the initial situation with the Given keyword
• describe events with the When keyword
• describe expectations with the Then keyword

Let’s take a simple example, as it would be written by a business analyst :

Given a student
Given a course
When the student registers in the course
Then the course must have the student as one of its student

Now, for each line, the developer creates a method and adds the right annotation to it:

public class AddCourseSteps {

    private Student student;

    private Course course;

    @Given("a student")
    public void aStudent() {

        this.student = new Student("dummy");
    }

    @Given("a course")
    public void aCourse(String label) {

        this.course = new Course("anotherDummy");
    }

    @When("the student registers in the course")
    public void heRegistersInACourse() {

        student.addCourse(course);
    }

    @Then("the course must have the student as one of its student")
    public void courseMustHaveStudent() {

        assertTrue(course.getStudents().contains(student));
    }
}

Notice how the “business” semantics is coded in the Java language. This example is of course trivial but higher-level stories would be treated just the same.

Running the story is just coding the test class in itself, which will tie the plain text description and the steps class and make the test class runnable in your favorite build tool and/or IDE. This wil produce the following trace:

Given a student
Given a course
When the student registers in the course
Then the course must have the student as one of its student (FAILED)

The FAILED part is of course only there is the test fails. You can object this is much ado about nothing, but only until now, because JBehave also let you parameterize your tests from the textual description, letting you write this:

Scenario: students are ranked according to marks

Given a course
Given a student named John Doe
Given a student named Jane Doe
When the first student obtains a A
When the second student obtains a B
Then first student is ranked 1 in the course
Then second student is ranked 2 in the course

Scenario: students are ranked according to marks or not ranked if they have no marks

Given a course
Given a student named John Doe
Given a student named Jane Doe
When the first student obtains a A
When the first student obtains a not_present
Then first student is ranked 1 in the course
Then second student is ranked not_ranked in the course

This can easily be written by business analysts.

To be frank, I didn’t use JBehave in any of my projects yet, but I intend to in the near future. I would rather be interested if anyone could give me feedback, mainly on v3.0. Otherwise, I encourage you to have a look at the JBehave site.

You can find the sources for the first example here in Maven/Eclipse format. I’ll let the second example as an exercise for the curious reader.

From http://blog.frankel.ch/automate-your-integration-tests