Note This page is very much a work in progress at the moment, and more features will be appearing here shortly.
There are two ways to run DbFit - through Java or through .NET. As a database developer, you do not have to know Java or .NET to write and run the tests. The only significant difference between the two implementations is that the Java and .NET versions support different databases.
DbFit/Java | DbFit/FitSharp | |
---|---|---|
Oracle | x | x |
SQL Server | x | x |
MySQL | x | x |
Postgres | x | |
Derby | x | |
HSQLDB | x | |
Sybase | x | |
DB2 | x | |
Teradata | * |
* The DbFit support for Teradata is experimental
Although FitNesse Wiki syntax is really simple, you do not have to use it to write scripts. You can write your tables in Excel (or almost any other spreadsheet program), and then just copy them into the FitNesse page editor. Clipboard automatically picks up data from most spreadsheet programs in tab-separated format, which can be directly converted to FitNesse with the Spreadsheet to FitNesse
button that is available when editing a page. If your spreadsheet program behaves differently, it should be able to export tab-separated files.
You can also convert a FitNesse table to tab-separated data with the FitNesse to Spreadsheet
button in page editor, and then copy that into Excel for editing.
DbFit has several ways to connect to the database. If you are working in an environment where you aren’t allowed to store database passwords in plaintext, you may wish to use the encrypt
utility that ships with DbFit to encrypt the password.
A new keystore is created when encrypt
is invoked for the first time. The default keystore filename is:
$HOME/.dbfit.jks
(%HOME%
under Windows).
It’s possible to create the KeyStore with other tools (eg java keytool
). In order to keep it compatible with DbFit - the same KeyStore format, key algorithm, alias and keystore password should be used. DbFit can only decrypt the password only if the same keystore was used to encrypt it. If the keystore file has been lost or destroyed - it will be impossible to decrypt the passwords generated with it.
You encrypt a password using encrypt
and use the encrypted string as password when configuring your DbFit connection settings. When a test is executed, DbFit decrypts the password and uses it to connect to the database. Both encrypt
and DbFit use a cryptographic key, which is stored in a password-protected file known as keystore.
encrypt
is provided both as a shell script (encrypt.sh
) and a Windows batch file (encrypt.bat
); the shell script will be used in the examples below.
Encrypt your password
encrypt.sh your-password-here
Output:
...
Encrypted Password:
ENC(jzDH1fYetwCp3JFfAeKebA==)
Copy the encrypted string into the database connection properties file
...
password=ENC(jzDH1fYetwCp3JFfAeKebA==)
...
No change is needed in the DbFit tests - the ConnectUsingFile
and Connect
fixtures work with both encrypted and non-encrypted passwords.
To place the keystore in an alternative location, specify the -keyStoreLocation
when invoking encrypt
:
encrypt.sh your-password-here -keyStoreLocation <some-path>
To allow the DbFit tests to decrypt passwords using the alternative path, you need to override the FitNesse COMMAND_PATERN
used for the execution of your tests (you can read more about FitNesse test execution here). This basically means that you need to add the following line in a parent page of your testsuite (ideally next to the line !path lib/*.jar
):
!define COMMAND_PATTERN {java -Ddbfit.keystore.path=<some-path> -cp %p %m}