Updated ui tests tutorial (markdown)

This commit is contained in:
Riccardo Nimser committed 2014-01-30 10:19:50 +00:00
1 parent 54af957093
commit 58028956f2
1 file changed
+12 -6
+12 -6
View File
@@ -5,7 +5,7 @@ In this tutorial, we want to give a practical introduction in how to write UI-Te
When you start to write UI tests, the first thing you have to do is, to ensure that the UI is testable. This means, that you have to be able to easily find all widgets in the final HTML-Document the user interacts with. The simplest approach here is to use debug identifiers which are provided by GWT and to assign an identifier to all important widgets, like buttons and text fields. Our framework contains a corresponding mechanism to lookup elements by the debug identifier, but more on this later.
If we look at the "Events" tab of the administration console, we can see that we need the button for adding a new event as well as the table for the validation of the creation (Listing 1). In addition we need all the text fields and the checkbox of the dialog for creating a new event, which are instantiated by the class `EventCreateDialog`, as well as for the dialog itself (Listing 2).
If we look at the "Events" tab of the administration console, we can see that we need the button for adding a new event as well as the table for the validation of the creation (Listing 1). In addition we need all the text fields and the checkbox of the dialog for creating a new event, which are instantiated by the class ´EventCreateDialog`, as well as for the dialog itself (Listing 2).
public class SailingEventManagementPanel extends SimplePanel implements EventRefresher {
public SailingEventManagementPanel(final SailingServiceAsync sailingService,
@@ -30,19 +30,19 @@ t
super(new EventParameterValidator(stringConstants, existingEvents), stringConstants, callback);
nameEntryField = createTextBox(null);
nameEntryField.ensureDebugId("NameTextField");
nameEntryField.ensureDebugId("NameTextBox");
nameEntryField.setWidth("200px");
venueEntryField = createTextBox(null);
venueEntryField.ensureDebugId("VenueTextField");
venueEntryField.ensureDebugId("VenueTextBox");
venueEntryField.setWidth("200px");
publicationUrlEntryField = createTextBox(null);
publicationUrlEntryField.ensureDebugId("PublicationUrlTextField");
publicationUrlEntryField.ensureDebugId("PublicationUrlTextBox");
publicationUrlEntryField.setWidth("200px");
isPublicCheckBox = createCheckbox("");
isPublicCheckBox.ensureDebugId("IsPublicCheckbox");
isPublicCheckBox.ensureDebugId("IsPublicCheckBox");
isPublicCheckBox.setValue(false);
}
}
@@ -77,4 +77,10 @@ Finally you should assign a debug identifier to the event management panel (List
sailingEventManagementPanel.ensureDebugId("SailingEventManagementPanel");
...
}
}
}
After you assigned an identifier to all widgets, you are almost done with the preparation. But, there is one more thing you should keep an eye on due the nature of GWT, which heavily use AJAX. If you look at the method `createNewEvent(final EventDTO newEvent)` of the class `SailingEventManagementPanel` as well as `fillEvents()`, which is called by the former one, you see that an `AsyncCallback` is passed to the service methods. In the background GWT creates an asynchrony request here and you don’t know when the request completes. Therefor you can’t tell how long you have to wait, before you can proceed with your test.
Our framework addresses this by providing a semaphore that counts pending asynchrony requests and the necessary code is automatically injected into the final HTML-Document by the base class `AbstractEntryPoint`. In the case you develop a new entry point, make sure you extend this one.
To use the semaphore you simply have to replace the `AsyncCallback` with a `MarkedAsyncCallback` and to rename the methods `onFailure` and `onSuccess` to `handleFailure` and `handleSuccess` (Listing 4).