Today we are talking about next topic in FitNesse tutorial series about Fitnesse Fixtures.

As discussed in the previous tutorials of this series, for every test we run, it has associated Java fixture which generates the actual output or result. Results are compared against the expected output on the FitNesse page. If result matches the expected output, the test is marked as passed and FitNesse page shows that result in green color. If result does not match the expected output, the test is marked as failed and FitNesse page shows that result in red color.

These colors are visible to the tester who is running the acceptance test on a particular application using FitNesse tool. In this tutorial, we are going to discuss in detail about the Java Fixture or code and how the request and response mechanism takes place through FitNesse web page.

FitNesse Request-Response Model:

For any test that we execute on FitNesse for a particular application under test, below are the steps involved.

• We click the test button on FitNesse web page, it start parsing the data present on the decision tables. Decision table column names are such that it has the same names as that of getters and setter present in the Java Fixture or code.
• FitNesse web page is interpreted by the testing engine (FIT or SLIM) which invokes the Java fixture based on the decision table parsed data. Decision table has a name which is written in camel case, this camel case name is nothing but the Java class fixture name. Columns names without question mark are setters and column names with question marks are getters. The values present in setter methods are the input parameters to Java class methods. This Java class invoking along with input parameters forms the request which is sent by the testing engine which anticipates a response.
• Testing engine after invoking the Java Class receives the response parameters that are present as getters in the decision table on the FitNesse web page. Getters methods present in the Java class do the actual test after looking up for required application data from its database.
• The response from testing engine is rendered on the FitNesse web page where the application output result is compared against the expected output. If output result matches with the expected output that portion on FitNesse web page turns green and test assertion count for right get increased by one. If output result does not match with the expected output that portion on FitNesse web page turns red and test assertion count for wrong get increased by one. This is demonstrated in the below screenshot.

In the above screenshot there are 4 right and 2 wrong assertions, therefore on the equal number of places in decision table getters columns are colored with green and red color respectively.

This completes FitNesse request response model explanation.

Java Fixture Rules in FitNesse:

In this section we are going to focus on the Java FitNesse fixtures. Below are the rules to write these.

package test;

public class TestMath {

    int firstNum;
    int secondNum;

    public int getFirstNum() {
        return firstNum;
    }

    public void setFirstNum(int firstNum) {
        this.firstNum = firstNum;
    }

    public int add() {
        int c = firstNum + secondNum;
        return c;
    }

    public int substract() {
        int c = firstNum - secondNum;
        return c;
    }

}

}

• FitNesse testing engine invokes Java class based on the name of the decision table. Therefore, first and foremost rule is that the name of FitNesse web page decision table should always match with Java class name. Here ‘Test Math’ decision table name matches with ‘TestMath’ Java class name.
• FitNesse testing engine gathers the values for input parameters through setter methods. These are the columns without question mark in decision table. Next rule suggests that a setter column name should always match with the setter method name present in the Java class. FitNesse testing engine automatically appends set- prefix to the name of the column in decision table. In the above example setter column names are ‘firstNum’ and ‘secondNum’, while interpreted by the testing engine these are appended by set- prefix and becomes ‘setFirstNum’ and ‘setSecondNum’ setter method names respectively. These are what present as setter methods in the Java class.
• The getter column names present on the decision table of a FitNesse web page should match as it is with the getter methods of the Java class or decision table name. Getter columns on the decision table are those with the question mark. Matching names of the getter methods gives knowledge to the testing engine for mapping the response and render the test color (red/green/yellow) accordingly. Also, the increase of the right and wrong assertion counts takes place here.

Above three rules are the most important rules to be kept in mind while writing any Java fixture for FitNesse test. After making sure on these rules, remaining rules for Java FitNesse fixtures are the basic Java programming rules which includes the import of required Java classes, packaging of these classes and compiling java files into binary class files.

Not only this, in order to make Java FitNesse fixtures look good, do the following standard practices.

• Java class name which is in camel case should make some sense i.e. it should not to be chosen in such a way that it does not resembles the testing subject at all. In the above example Java class name chosen was TestMath which gives a rough idea that this is related to test something in mathematics.
• Like Java class name, getter and setters names should be well chosen and those names should make sense. In the above example, we have chosen ‘setFirstNum’ and ‘setSecondNum’ as the setter which implies that here we need to set input values for first and second numbers. Similarly getter names are add and subtract which makes an absolute sense that here we are doing addition and subtraction operations respectively.
• Also, the Java code for fixture should be properly indented such that it should be easy to read and clear to understand.
• While writing Java code avoid writing dead code (unreachable code), duplication of code or testing logic, just maintain short and sweet approach.
• If a method has lots of statement consider breaking it into sub methods when same piece of code is required over and over in the same class. If that piece of code is required in many classes then consider making a generic class with this method so that it can imported in Java classes when needed for implementation.

⇓ Subscribe Us ⇓

If you are not regular reader of this website then highly recommends you to Sign up for our free email newsletter!! Sign up just providing your email address below: