How Business Rules Table Execution works

This section explains the technical details of how a Business Rules Table gets executed.

The underlying Fixture of a Business Rules Table exposes set methods for each Input column. The Fixture exposes a method by the same name as the column for an Assertion column.

When Business Rules Table is created, two methods "setUp" and "tearDown" are created along with other columns in the underlying fixture. "setUp" method is executed before execution of each row and "tearDown" method is executed after execution of each row.

Consider the Rules Table below,

column AcolumnB?
helloworld

During execution, an instance of the underlying Fixture gets created for the Rules Table.

For each row in the Rules Table, the Fixture instance gets populated with the values defined. So, for the first row, setColumnA("hello") gets invoked.

For Assertion columns, a method by the same name gets invoked. So, for the first row above, columnB() is invoked and the output is compared against the expected value "world".

Assertion columns are assumed to compare textual comparisons, by default. Therefore, the underlying method for an Assertion column returns a "String".

You can modify the type of the returned value to suit your need.

While performing the verification, Twist would automatically perform the appropriate comparison. So, if
public String columnB() {
    return ""; // Calculate and return the value to be checked
}
were to be modified as
public Integer columnB() {
    return 1; // Calculate and return the value to be checked
}
then you could have a Rules Table as shown below:
column AcolumnB?
hello1