Standalone and flow mode comparison

This is an excerpt from Test Driven .NET Development with FitNesse (ISBN 978-0-95568-360-2, published by Neuri Limited), reproduced on this site with the publisher's permission. Copyright and all rights are reserved by Neuri Limited

DbFit fixtures can work in two modes:

• In flow mode: a DatabaseTest fixture controls the whole page and coordinates testing. You can use other fixtures as well, but no other fixture can take over flow mode processing. In flow mode, DbFit automatically rolls back the current transaction at the end to make tests repeatable, and provides some additional options such as inspections of stored procedure error results.
• Standalone: you can use individual fixtures without having DatabaseTest coordinate the whole page. In this case, you are responsible for transaction management. This enables you to have more control over the database testing process, and even supply your own database connection to make sure that .NET integration tests are running in the same transaction.

The mode in which you are using DbFit fixtures affects how you connect to the database.

If you can, use flow mode. It gives you automatic transaction management and some other shortcuts. If your test relies on some other fixture controlling the page in flow mode, use standalone fixtures. The syntax is, in most cases, absolutely the same.

In flow mode, the current database connection is kept in a protected field of the DatabaseTest instance. SqlServerTest is a subclass of DatabaseTest that just initialises it to work with SqlServer 2005. Use the Connect method to initialise the database connection. Pass the server (optionally followed by the instance name), username, password and the database name as arguments. This is how I connect to a SqlServer 2005 Express 1) instance on my laptop:

!|dbfit.SqlServerTest|

!|Connect|LAPTOP\SQLEXPRESS|FitNesseUser|Password|TestDB|

If you are connecting to a default database, you can omit the fourth parameter. If you want to use non-standard connection properties, or initialise your connection differently (for example, using Windows integrated authentication), call Connect with a single argument — the full .NET connection string. Here is an example:

|Connect|data source=Instance;user id=User;password=Pwd;database=TestDB;|

For flow mode to work correctly, the SqlServerTest fixture must be the first one on the page — not even import can be before it. This is why we explicitly specify the namespace.

In standalone mode, the connection properties are stored in the public DefaultEnvironment singleton field inside dbfit.DbEnvironmentFactory. You can initialise it from your own fixtures if you want to pass an existing database connection (to make sure that your .NET tests are using the same transaction as DbFit fixtures). Alternatively, you can use the DatabaseEnvironment fixture from the dbfit.fixture package to define the connection. To change the default environment (or initialise it for the first time), pass the new environment type as the first argument to the fixture. For SqlServer 2005, the value of this argument should be SQLSERVER. DatabaseEnvironment is a SequenceFixture (see tip “Can I use flow mode without weird method names?” on page 79) that wraps the DefaultEnvironment singleton as a system under test, so that you can then call all its public methods directly — including the Connect method explained earlier.

|import|
|dbfit.fixture|

!|DatabaseEnvironment|sqlserver|
|Connect|LAPTOP\SQLEXPRESS|FitNesseUser|Password|TestDB|

Notice that there is no space between DatabaseEnvironment and Connect — they have to be in the same table. Because we are not using flow mode, we can use the import fixture as well. Most DbFit fixtures are in dbfit.fixture namespace, so it is good practice to include this namespace.

Yes, in different tests. Note that the imported namespace may give you some problems in flow mode. If you want to mix and match, then either do not import the dbfit.fixture namespace for standalone tests, or use the utility Export fixture to cancel the namespace import after the standalone test.

!|dbfit.util.Export|
|dbfit.fixture|

In flow mode, the current transaction is automatically rolled back at the end of the page. If you want to commit it to make changes permanent, put the Commit table into the page. There are no arguments or additional parameters — the table contents contain just this one word. Likewise, you can roll back manually in your test using the Rollback table.

In standalone mode, use the DatabaseEnvironment fixture again, but do not specify a fixture argument. This tells the DatabaseEnvironment to use the current default database connection, without attempting to initialise it. Call Commit or Rollback in the second row.

!|DatabaseEnvironment|
|rollback|

It is a very good idea to put this table in a TearDown page for your test suite when you use standalone DbFit fixtures. This will make sure that your tests are repeatable. All the fixtures described in the rest of this chapter are in the dbfit.fixture namespace. In flow mode, do not use the fixtures directly, but instead call methods of the DatabaseTest class. The appropriate methods have the sane names as the fixtures they relate to. If you import the namespace for standalone fixtures, the table syntax in both modes is absolutely the same.