...

• 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 nonexistant 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 combitnation 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

Validation of results

• As a first pass, a test 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.As a second pass   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.

Executing Acceptance Tests

...