Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I've successfully test-driven the development of Swing and GWT applications through the GUI.</p> <p>Testing "just behind the GUI" ignores the integration between the model code and the GUI components. The application needs to hook up event handlers to display data in the GUI when the model changes and receive input from the GUI and update the model. Testing that all those event handlers have been hooked up correctly is very tedious if done manually.</p> <p>The big problem to overcome when testing through the GUI is how to cope with changes to the GUI during development.</p> <p>GWT has hooks to help with this. You need to set debug IDs on the GWT widgets and import the DebugID module into your application. Your tests can then interact with the application by controlling a web browser, finding elements by their id and clicking on them or entering text into them. <a href="http://webdriver.googlecode.com" rel="nofollow noreferrer">Web Driver</a> is a very good API for doing this.</p> <p>That's only the start, however. You also need to decouple your tests from the structure of the GUI: how the user navigates through the UI to get work done. This is the case whether you test through the GUI or behind the GUI against the controller. If you test against the controller, the controller dictates the way that the user navigates through the application's different views, and so your test is coupled to that navigation structure because it is coupled to the controller.</p> <p>To address this, our tests control the application through a hierarchy of "drivers". The tests interact with drivers that let it perform user-focused activities, such as logging in, entering an order, and making a payment. The driver captures the knowledge of how those tasks are performed by navigating around and entering data into the GUI. It does this by using lower-level drivers that capture how navigation and data entry is performed by "gestures", such as clicking on a button or entering text into an input field. You end up with a hierarchy like:</p> <ul> <li>User Goals: the tests verify that the user can achieve their goals with the system and demonstrates how those goals are achieved by a sequence of...</li> <li>User Activities: things the user does through the GUI, represented as drivers that perform...</li> <li>Gestures: low level mouse and keyboard input to control the GUI.</li> </ul> <p>This hierarchy that is often used in the user-centered design literature (although with different terminology).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload