Test servers

Scenarios must be executed on a running server. A server that is used to run scenarios is often referred to as a test server. Note that there is no flag, setting, or configuration parameter that inherently marks a server as a test server. A test server is simply a server on which tests are run.

Test server configuration

Test servers are often configured to run with settings that are appropriate for running tests, as opposed to settings appropriate for a production environment. The following describes some common test server settings.

Test server modes

A server can be started in one of three modes: development, test, and production. In development mode, all implementation and testing features are enabled. In test mode, all implementation and testing features are disabled, except for the ability to enable and advance the testing clock. Test mode is designed for testing functionality in a production-like environment with the one exception of being able to advance the clock to test time-based processes. In production mode, all implementation and testing features are disabled.

Test servers are typically started in either development mode or test mode.

For more information on server modes, refer to the section on server modes in the System Administration Guide.

Test server database

Test servers are often configured to store the database in memory only. When the server is started, a new database is created. When the server is stopped, that database is discarded. An "in memory" database has the advantage of providing a more stable testing environment. The database is always discarded and recreated, which means there is less chance that a valid test will fail because of the presence of unexpected data from a previous test or from some other process.

The database-config.xml file specifies different database configurations using the <database> tag. In the base configuration, test servers are run using the <database> configuration with the env="h2mem" property. This configuration specifies an H2 server whose database is in memory. Specifically, the jdbc-url property starts with jdbc:h2:mem:....

Assertions enabled

An assertion is a method that tests to see whether a desired behavior has been correctly executed within an application. Gosu includes assertions, which are an extension of assertions in Java.

When an assertion is enabled, it checks to see whether a given outcome has occurred. If the outcome has occurred, the assertion does nothing. If the outcome has not occurred, the assertion throws an error, which can be captured by a testing framework and included in a report or shown to a user.

By default, assertions are disabled in InsuranceSuite applications. This means that whenever an assertion is reached during run-time, it does nothing.

Typically, a test server is configured to have assertions enabled. This means that whenever an assertion is reached during run-time, it is executed. If the assertion fails, the exception can be logged or shown to a user.

To start a server with assertions enable, the server must be started with the flag -ea. This is the same flag used to enable assertions in Java programs.

Test server ports

Test servers are often configured to run on a unique port. This helps to isolate the test environment and to ensure that other processes or users do not inadvertently connect to the test server.

Starting and stopping test servers

You can initiate the running of a scenario, feature file, or test suite whether there is a test server running or not.

If there is a test server running, Behavior Testing Framework runs the scenarios on that test server. When the scenarios are complete, the server is left running.

If there is no test server running, Behavior Testing Framework starts a test server, runs the scenarios on that test server, and then stops the test server.

If you plan to run multiple feature files or test suites in an ad hoc manner, you can start a test server and then run the scenarios as needed. This may be more efficient as the test server needs to execute the start-up process only once.

Important: There is a known issue with Behavior Testing Framework 10.0.1. If there is a running test server and you run a test suite, the test suite is not able to run properly and Behavior Testing Framework throws an ArrayOutOfBounds exception. As a workaround, stop the test server before running a test suite.