Using WebTest & DbFit together

If you are testing a web application, there is a good chance that you will need to manipulate or verify some data in a database as part of your testing of the front end application.

It would seem obvious to use DbFit and WebTest on the same test, however you should be aware of a few things.

WebTest is a DoFixture, and DbFit can work in two modes, flow or standalone, you will need to use the standalone mode of DbFit when using DbFit with another fixture..

When creating the SetUp page for the suite of tests add the fixtures like this:


!|com.neuri.webfixture.WebTest|
!|import|
|dbfit.fixture|
!|DatabaseEnvironment|sqlserver|
|Connect|serverSQLEXPRESS|FitNesseUser|Password|TestDB|

Note that there isn’t a gap between DatabaseEnvironment and Connect, they must be in the same table

You can also connect to DbFit with the Connect table.

Also remember that since you’re using standalone mode of DbFit, it wont rollback or commit, so you will need to use the following tables to commit or rollback transactions:


!|DatabaseEnvironment|
|Commit|

!|DatabaseEnvironment|
|Rollback|

We use the WebTest fixture and DbFit together and it works very well for us. However we have also extended WebTest to include some SQL features in WebTest that allow us to do simple SELECTS and use the output to verify what should be on screen without breaking the flow of the test.

Using WebTest & DbFit together

If you are testing a web application, there is a good chance that you will need to manipulate or verify some data in a database as part of your testing of the front end application.

It would seem obvious to use DbFit and WebTest on the same test, however you should be aware of a few things.

WebTest is a DoFixture, and DbFit can work in two modes, flow or standalone, you will need to use the standalone mode of DbFit when using DbFit with another fixture..

When creating the SetUp page for the suite of tests add the fixtures like this:


!|com.neuri.webfixture.WebTest|
!|import|
|dbfit.fixture|
!|DatabaseEnvironment|sqlserver|
|Connect|server\SQLEXPRESS|FitNesseUser|Password|TestDB|

Note that there isn’t a gap between DatabaseEnvironment and Connect, they must be in the same table

You can also connect to DbFit with the Connect table.

Also remember that since you’re using standalone mode of DbFit, it wont rollback or commit, so you will need to use the following tables to commit or rollback transactions:


!|DatabaseEnvironment|
|Commit|

!|DatabaseEnvironment|
|Rollback|

We use the WebTest fixture and DbFit together and it works very well for us. However we have also extended WebTest to include some SQL features in WebTest that allow us to do simple SELECTS and use the output to verify what should be on screen without breaking the flow of the test.

I Hate FitNesse / Fitnesse Rocks!


I want you to know that i have a love hate relationship with fitnesse.

I have been using it for several months now and sometimes i really hate it; i still use it and advocate its use, but i still hate it. Tim Ottinger summed up using FitNesse really well over on the FitNesse group (yahoo) . He said that Using Fitnesse is not unlike trying to teach a dog to sing. Its not that the dog is a bad singer, its simply a miracle that it can sing at all.

And its true. FitNesse is not a great wiki, but it does do wiki. It doesn’t work very well in CI, but it can be integrated into CI. It has its own versioning that isn’t great (millions of zip files), but it can be versioned traditionally (using SVN or CVS). It doesn’t have any metrics (test execution over time, defects, test coverage), but you can get those through CI or integration with another tool (we are experimenting with integration into Quality Center [sic]).

There is also the big issue of user management. There several authentication methods supported by FitNesse:

  1. No authentication (default), anybody can do any thing!
  2. UserPassword: Defines one user and its password on fitnesse start: … -a userA:passworA
  3. PasswordFile: For multiple users, read once on fitnesse start, so adding new users requires a restart ffs.
  4. LinuxPAM plugin: Use PAM to access Linux user passwords, requires a plugin.
  5. Provide your own AuthenticatorClass as plugin.

Given a choice i’d opt for the PasswordFile mode but then administration becomes tiresome.

For more info on user management checkout:

I Hate FitNesse / Fitnesse Rocks!


I want you to know that i have a love hate relationship with fitnesse.

I have been using it for several months now and sometimes i really hate it; i still use it and advocate its use, but i still hate it. Tim Ottinger summed up using FitNesse really well over on the FitNesse group (yahoo) . He said that Using Fitnesse is not unlike trying to teach a dog to sing. Its not that the dog is a bad singer, its simply a miracle that it can sing at all.

And its true. FitNesse is not a great wiki, but it does do wiki. It doesn’t work very well in CI, but it can be integrated into CI. It has its own versioning that isn’t great (millions of zip files), but it can be versioned traditionally (using SVN or CVS). It doesn’t have any metrics (test execution over time, defects, test coverage), but you can get those through CI or integration with another tool (we are experimenting with integration into Quality Center [sic]).

There is also the big issue of user management. There several authentication methods supported by FitNesse:

  1. No authentication (default), anybody can do any thing!
  2. UserPassword: Defines one user and its password on fitnesse start: … -a userA:passworA
  3. PasswordFile: For multiple users, read once on fitnesse start, so adding new users requires a restart ffs.
  4. LinuxPAM plugin: Use PAM to access Linux user passwords, requires a plugin.
  5. Provide your own AuthenticatorClass as plugin.

Given a choice i’d opt for the PasswordFile mode but then administration becomes tiresome.

For more info on user management checkout: