Sponsored Link •
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.
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
"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.
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
setUpSuite is called prior to executing each
tearDownSuite after. When
the runner invokes
setUpSuite on each
Suite class listed in the recipe file, the
Map it passes to
the settings as key value pairs. For example, if the recipe file
contained the setting property
Map passed to
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