Advertisement

Summary
This article shows you how to pass context to unit and conformance tests by supplying settings properties to Artima SuiteRunner.

When developing software, you often pull out certain parameters from the source code and make them configurable. This way when those parameters need to be changed, you (or perhaps a field-service engineer or user) can modify a configuration file. You need not go in and change hard-coded values and recompile the source code to modify those parameters. The software reads the configuration file and sets the parameters dynamically.

This need to make software configurable can also be true for tests. If your tests use certain parameters that change often, or that need to assume different values for different runs, you may feel the urge to make your tests configurable. Just like any other software, for certain parameters used by your tests, you may prefer to specify the values in a configuration file or on the command line instead of in the source code. For example, when testing with a database, you may want to make configurable the database name, the user and password for accessing the database, and the port and server on which the database is running, rather than hard-coding these values in the source code.

As of version 1.0beta7, Artima SuiteRunner allows you to specify configuration parameters called "settings" for individual runs. These settings, which may be specified on the command line or in a recipe file, can be accessed and used by your test classes. This article will show you how to supply settings to Artima SuiteRunner and access them from your test classes.

Specifying Settings in Recipes

Prior to version 1.0beta7, every Artima SuiteRunner recipe file contained three properties that defined the runpath, reporters, and suites for one run. A runpath is a list of directories, JAR files, and URL code bases from which to load classes during the run. Using the runpath, SuiteRunner executes the specified suite classes, employing the specified reporter classes to collect test results during the run. Here's the contents of an example recipe file:

org.suiterunner.Runpath=-p "dir1 dir2"
org.suiterunner.Suites=-s MySuite -s MyTestCase
org.suiterunner.Reporters=-g -f test.out -eFAB

As of version 1.0beta7, you can now specify any number of other properties in the recipe file. These other properties are settings. Settings can be named anything so long the name does not begin with "org.suiterunner.", which is reserved for SuiteRunner itself. For example, you could specify a database name in the recipe file like this:

org.suiterunner.Runpath=-p "dir1 dir2"
org.suiterunner.Suites=-s MySuite -s MyTestCase
org.suiterunner.Reporters=-g -f test.out -eFAB
dbname=testdb

In this example, the dbname property is a setting.

Accessing and Using Settings

In version 1.0beta7, we added two methods to class Suite that allow you to access and use the settings in your test classes:

public void setUpSuite(Map context)
public void tearDownSuite()

Similar to the way setUpFixture is called prior to invoking each test method, and tearDownFixture after, setUpSuite is called prior to executing each Suite, and tearDownSuite after. When the runner invokes setUpSuite on each Suite class listed in the recipe file, the Map it passes to setUpSuite contains the settings as key value pairs. For example, if the recipe file contained the setting property dbname=testdb, the Map passed to setUpSuite would contain the key "dbname" mapped to the value "testdb". To access this setting, you must override setUpSuite in your Suite subclass. In your implementation of setUpSuite, you can retrieve the database name from the context Map, and set up the database connection for the test. Because you are opening a database connection in setUpSuite, you will likely want to override tearDownSuite and close the database connection.