In Fitnesse tutorial series last article we talked about “Writing The Fitnesse Fixtures – With Fitnesse Java Example“. In today’s class we are covering “Configuring FitNesse (FIT and SLIM)”.
FIT Testing Engine
FIT (Framework for Integrated Testing) is the testing engine in FitNesse tool which executes the test table by using the Fixture code. FitNesse is HTML and wiki “front-end” to FIT. FIT testing engine makes it possible to run test tables; but itself does not provide an easy way of creating those tables or displaying the results of those tests. This is where FitNesse comes into picture. FitNesse tool made it really easy to create, run, organize, annotate, and share FIT tests throughout.
Configuring FIT Test System:
To run a FitNesse test page under FIT protocol, we need to set TEST_SYSTEM variable to “fit”.
Syntax: !define TEST_SYSTEM {fit}
If above variable is set on your page or on any parent page, then that page will run through FIT testing engine. Below are the fit tables.
- Column Fixture: In this style, we use rows of data that represent inputs and expected outputs. It is easy to design and understand. The top row of the table represents the name of the Column Fixture Code that Fit engine will use to process the table. The second row specifies the inputs and outputs of the fixture code. One with question mark is for output result and ones without question marks are input.
- Row Fixture: It is used for testing queries which return an exact set of values (order-independently). In this structure, the prime column represents a key that identifies one of the records that we expect to get back and the rows of data that represent the output we expect to get back (no more and no less than that exact set of records).
- Action Fixture: In this style, we can write a script that emulates a series of events or simple actions such as entering, pressing, and checking.
- Comment Tables: It is a table to enter all the comments and it does nothing. Comment tables are not executed as a test.
SLIM Testing Engine
SLIM (Simple List Invocation Method) is an alternative testing engine to FIT. It is light weighted as compared to FIT testing engine. It has a very small kernel that implements the SLIM protocol. Using such protocol has the following advantages.
- The Slim protocol is very easy to port. Therefore, to get a new platform ready to use SLIM is just a matter of few hours of work.
- SLIM testing engine has all the features on the FitNesse side, so the test tables remain consistent regardless of the platform of the SUT (System under test).
- Using this protocol, we can explore new test syntax’s as HTML is not an intrinsic part of SLIM.
Setting up the SLIM Test System and associated Tables:
To run a FitNesse test page under SLIM protocol, we need to set TEST_SYSTEM variable to “slim” instead of “fit”.
Syntax: !define TEST_SYSTEM {slim}
If above variable is set on your page or on any parent page, then that page will be run with Slim Protocol. Below are the slim tables.
- Decision Table: It supplies the inputs to testing engine and compares the result with expected output for decisions. This is similar to the Fit Column Fixture.
- Dynamic Decision Table: It has the similar syntax as that of decision table but it passes the column headers as parameters to the fixture.
- Query Table: The row in a query table supplies the expected results of a query. This is similar to the Fit Row Fixture.
- Subset Query Table: This table tells the slim table processor that this is a subset query table. It supplies subset of the expected results of a query. Subset query tables resembles to Query tables except that we only need to put those rows into the query table which we want to make sure to exist in the query response.
- Ordered query Table: It supplies the expected results of a query. All it requires is that the rows are expected to be in order. This is similar to the Fit Row Fixture.
- Script Table: This table has a series of actions and checks. Similar to Do Fixture.
- Table Table: The “Table” table allows us to write a fixture that accepts an arbitrary table (input), and returns a table of results (output). The table of results has a similar geometry to the input table (excluding the first row).
- Import: The Import table adds a path to the fixture search path. It tells the Slim Executor where the fixtures are located.
- Comment: It is just a table to mention all the comments and it does nothing. Comment tables are not executed.
- Scenario Table: It is a table that can be called from other tables i.e. from Script Table and Decision Table. The format of a Scenario table is the same format as that of a Script Table, off course with a few differences.
- Library Table: It is a table which is used to install support fixtures available for all test pages, so that they are available for all pages underneath. The Library table format is similar to the Import Table.
- Define Table Type: It is a helper table that defines the default table type for named fixtures. It is actually designed to help us writing more readable tests.
- Define Alias: It is a helper table that defines alias names for fixtures. It help us to segregate requirements from the implementation.
Data Types: The data in all of above tables is always String. Slim testing engine has standard data type converters which automatically convert the strings in these tables into the data types expected by the fixtures.
Configuring SLIM: SLIM system can be configured for the following properties:
Properties | Value | Description |
slim.port | 8085 | It is the base port for SLIM testing engine. |
slim.pool.size | 10 | FitNesse by default uses the ports 8085 up to 8095 (slim.port +slim.pool.size). This parameter defines the size of the pool of ports that could be used in a cycle. |
slim.host | localhost | If defines the host URL for the SLIM server where it is running. If you are running FitNesse on the local machine then it will be localhost by default. If the machine is remote SLIM server then it configured for the IP address or host name. |
slim.flags | These are the extra flags to provide to the SLIM server. Arguments which are supported by the slim service are as follows:
[-v] [-i interactionClass] [-s statementTimeout] [-d] [-ssl parameterClass] | |
slim.timeout | 20 seconds | It is the time value in seconds defined for connection timeout starting and finishing a test run on SLIM testing engine. |
slim.debug.timeout | slim.timeout | It is similar to that of slim.timeout parameter, but this come in picture only when the debug property is set (falls back to slim.timeout). |
manually.start.test. runner.on.debug | false | This is Boolean flag, when false it does not launch a SLIM server when the test is running in debug mode. |
Above slim properties are well define in the plugins.properties file of FitNesse tool.
⇓ 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!!!
- Tutorial 1 – Introduction to FitNesse Testing Tool
- Tutorial 3: Getting Started With First FitNesse Project
- Tutorial 4: Writing The Fitnesse Fixtures – With Fitnesse Java Example
- Creating A New FitNesse Test
- Running Tests And Organizing Tests In Fitnesse
- Tutorial 9 – Using Slim Test Table Styles in Fitnesse
- Tutorial 10 – Using Decision Table and Query table in Fitnesse
- Guide on the Script Table in FitNesse with an example
- BDD Style Testing using FitNesse
- Creating The Test Suite In FitNesse