Using a Decision Table and Query table in FitNesse tutorial, we are going to discuss three SLIM testing engine table types. These are:
- Query table.
- Subset Query table.
- Ordered Query table.
As discussed in the last tutorial, in order to work on the query, subset query and ordered query tables, we need to define TEST_SYSTEM as slim. This is the first requirement before we start writing fixtures and FitNesse tests using these tables.
!define TEST_SYSTEM {slim}
If the above variable is set on your current FitNesse page or on any of the parent page, then your page will be run with the slim test system and we can work on these query tables. Let’s discuss them in detail.
Query Table:
Query table supplies the expected results of a query. It is similar to the Fit Row Fixture. To work with the Query table, we need to do the following.
- Mention Query: in the first cell of the table. This statement informs the slim table processor that it is a query table.
- It has the constructor argument, which accepts the value. In the below example, the constructor is “QueryTable” which accepts a date as an argument.
- Query table column headers are field names. The equivalent fixture class must have a query method that returns a list of rows.
- Each row has a list of fields. Each field in a row is a two-element list composed of the field name and its string value. E.g. asList (“company ID”, “AO1”), etc.
This is the query table structure; operationally FitNesse slim test system checks each row in the table to see if there is a match in the query response. The matching sequence for the fields is left to right. If the leftmost field matches, then the row is considered to be “found” and the fields that don’t match are marked in error (in red color). For example, when the department “Quality Analyst” does not match with “Developer”, it will be marked with red color.
Few Points to Remember About Query Table:
- If we leave the blank cell in a table then it will be filled with the result returned from fixture but it will be counted as ignored.
- If the first cell of a row cannot be matched, then the row will be considered as missing.
- If there is an unmatched row remaining in the query response, it is added to the table and marked surplus. The order of the rows in the query table is irrelevant.
- Always the query function is called before a table method when it is declared in the fixture. It will be passed a list of rows which are themselves lists of cells.
- In analogy to decision tables, we can define comment columns by prefixing the header with the hash symbol (#).
Java Fixture used for Query table demonstration: Like any ordinary Java class, this fixture has a constructor that can accept arguments, a table method and a query method that returns the table data as rows and columns in the form of lists within in a list. E.g. list (list1, list2). This fixture is demonstrated below.
FitNesse Test Screenshot for Query table (Scenario 1): In this scenario, one of the columns in the query table does not match with the result; it is marked with red color. Remaining all columns or cells are marked with green color.
FitNesse Test Screenshot for Query table (Scenario 2): In this scenario of the query table, all cells in the table are matching with the result set. Therefore, the entire FitNesse test page is green all around.
Subset Query Table:
Subset query table supplies a subset of the expected results of a query. To work with Subset Query table, we need to do the following.
- Mention Subset Query: in the first cell of the table. This statement informs the slim table processor that this is a subset query table.
- Subset query tables are almost identical to Query tables and have similar table structure as discussed above. The only difference is that we only need to put those rows into the table that we are sure to exist in the query response.
In the above subset query table, we used the existing query table fixture and tested the FitNesse page with fewer numbers of columns instead of all rows and column pairs as in the case of Query table.
Ordered query Table
Ordered query table supplies the expected results of a query. In this table, the rows are expected to be in order. This slim table function is similar to the Fit Row Fixture. To work with Ordered Query table, we need to do the following.
- Mention Ordered Query: in the first cell of the table. This statement informs the slim table processor that this is an ordered query table.
- Ordered query tables are almost identical to Query tables and have a similar table structure as discussed above. The only difference is that the order of the rows in the table must be the same as the order of the rows returned by the query.
Few Points to remember about Ordered Query table:
In an ordered query table, the order of the returned rows is very important and it has a matching algorithm. The matching algorithm is relative which means that if the ordered query table rows have the following order {A, B, C, D} and the query returns {B, C, D, A} then rows B, C and D will be green, and only row A will be marked in red as it is “out of order: row 1”. This is to be noted that the row number in the error message is the ordinal position (based on 1) of that row in the query result as shown below.
Based on the above facts this is inevitable that the first row in the table can never be out of order in case of an ordered query table. Also, if we repeat any such row or add a number of rows that returned by the result that, FitNesse will be marked any such extra row as missing. Such a scenario is shown above.
⇓ 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:
Happy Testing!!!
