Page Comparison

...

Here is an example of an existing test from GroupTest.java:

@Test(sequential = true, groups = {"group","acceptance","ui"})

 @SuppressWarnings("PMD.SignatureDeclareThrowsException") // one of the dependent methods throws Exception

 public void createGroupInPartialApplicationStateTest() throws Exception {

 initRemote.dataLoadAndCacheRefresh(dbUnitUtilities, "acceptance_small_001_dbunit.xml", dataSource, selenium);

 CreateGroupEntryPage groupEntryPage = loginAndNavigateToNewGroupPage();

 CreateGroupSubmitParameters formParameters = getGenericGroupFormParameters();

 CreateGroupConfirmationPage confirmationPage = groupEntryPage.submitNewGroupForPartialApplication(formParameters);

 confirmationPage.verifyPage

();
 GroupViewDetailsPage groupDetailsPage = confirmationPage.navigateToGroupDetailsPage();

 groupDetailsPage.verifyPage();

 groupDetailsPage.verifyStatus("Partial Application

*");
 }

Might be written something like:

...

\*

\* Given Center exists,

\* And there is a user with rights to create a group,

\* When I login in as user "mifos"

\* And I create a Group with generic parameters

\* And I view Group Details

\* Then Group status is "Partial Application"

*/

@Test(sequential = true, groups = {"group","acceptance","ui"})

@SuppressWarnings("PMD.SignatureDeclareThrowsException") // one of the dependent methods throws Exception

public void createGroupInPartialApplicationStateTest() throws Exception

 {
//Given
initRemote.dataLoadAndCacheRefresh(dbUnitUtilities, "acceptance_standard_dbunit.xml", dataSource, selenium)

;
Center center = createCenter(getGenericCenterFormParameters())

;

//When

login("mifos")

;

Group group = createGroup(center, getGenericGroupFormParameters()

);
GroupDetails groupDetails = viewGroupDetails(group)

;

//Then

groupDetails.verifyStatus("Partial Application*")

;
}

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.

...