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

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

Consider the Rules Table below,

column A	columnB?
hello	world

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".

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 A	columnB?
hello	1