...
There are two different kinds of data sets, validation and start data sets. Validation data sets are used to make sure that at the end of a test, the database looks correct. As of Jan 2011, we are working to eliminate the use of validation data sets. Start data sets are used to set up a suitable environment for each test case and they're usually loaded at the very beginning of the test.
...
- a txt file that describes what the data set consists of and/or its purpose.
- a zipped an xml file which is the DBUnit representation of the database (a dump).
...
- load an existing data set (or generate a new one as described above)
- record acceptance test operations using Selenium IDE
- if you will validate against a final database state, then dump the final database state (at the end of the operation) and create a new data set using DbUnitDataImportExport as described above
- write the acceptance test java code (such as CollectionSheetEntryTest.defaultAdminUserEntersSingleLoanPayment) which: _ loads an initial database state _ includes transitions to the page objects which map to the pages traversed during the test and any required data entry
- use the acceptance test code (with initially nonexistent methods) to generate (via Eclipse) the empty classes and methods that need to be implemented
- using existing page objects as examples and the Selenium IDE generated code, fill in the page object code needed to make the test functional
- test name should be a combination of words which describes the main purpose of the test
- test should verify that data entered on the create page are displayed properly on the preview page
- while writing the test remember to use appropriate line spacing to make the code easy to read
- it's good practice to add comments in the code which explain what is verified at each step of the test
Executable Specification Style (added Jan 2011)
To make acceptance tests more clear in their intent, we will write tests to with a executable specification style that uses internal test drivers or helpers to separate the test into two layers - a test implementation layer and a lower helper or application driver layer. The acceptance test is written using internal domain specific language (test helpers) e.g. "createClient" as developed by the test authors. These tests will be written using a Given, When, Then structure. "Given" is the set up of the test case, "When" is the activity between the user and Mifos, and "Then" is the expected result. This style and the concept of layered acceptance tests is described in more detail in Continuous Delivery, Chapter 8. The goal of including this style is to simplify test writing and maintenance. While the tests will be similar to behavior driven tests, we will still write tests in a Java to take advantage of its full development environment. Some of these helpers could use Service Facade or API's of Mifos to build entities to support more complex use cases.
Here is an example of an existing test from GroupTest.java:
Validation of results
- Test can validate success against html elements. For example, Changing status of an account and checking for the new status being displayed to the user. Doing validation against the UI is faster and takes less maintenance than validating tests with dbunit. Some existing test do validate with dbunit, so the following information is left here for reference on those tests:
- a test can include dbunit validation based on changes between the initial database state and the final database state as captured above. When validating against the database, here are a few guidelines:
- Get a data set for only the tables relevant to the test case verification. This reduces the chance of spurious results and also reduces the complexity of the test case.
- For our framework, any table you are inspecting needs to be included in the map "columnsToIgnoreWhenVerifyingTables" found in the DbUnitUtilities class. When adding a table to this map, identify the columns for the table that should be ignored. Columns to ignore typically include generated ID counters and dates.
- Before comparing the results of the expected and actual data sets, the results may need sorted to ensure a consistent order. For some transaction tables, the data may be stored in the database by multiple threads, which results in different ordering per test run. To compare results for these types of tables, try sorting on other more stable information such as amount/fee.
- To debug the expected and actual data sets, use the printTable method found in the class DbUnitUtilities.
...