Hi, All: Antranig, Alan, Avtar and I have been having a side conversation about a specific use of gpii-webdriver <https://github.com/GPII/gpii-webdriver>. That discussion has become general enough that it's time to involve the wider group.
Just as a reminder, gpii-webdriver runs within node, and launches an actual browser (currently, Chrome). It can send mouse events and key clicks defined using IoC test steps to that browser. It can also send code to be executed on the client side and receive a serialized and deserialzed set of results from the client side. Finally, it can listen for markup changes and other key browser events from within IoC test steps. You might use gpii-webdriver if: 1. You want to test keyboard navigation between components. 2. You need to interrogate both server side and client-side components in a single test sequence. 3. You need to test navigation between pages or browser history manipulation. 4. You want to make use of its built-in aXe and Google Accessibility Developer checks. In this case, Alan and Avtar are using the aXe integration to verify that an animation widget passes the checks after it reaches a given state. They hit timing problems waiting for the component to reach the right state. If there is a set of known markup that can always be found once the state has been reached, you can wait for that markup to appear and then continue. In this case, the timing was such that the only markup change was not consistently triggered once the component had reached the desired state. Instead, they ended up waiting for 3 seconds and continuing. This works for the time being, but is brittle, and likely to result in spurious test failures depending on the speed of your machine. The long term solution we've discussed is to update gpii-webdriver to enable relaying between the client and node side (see GPII-1574 <https://issues.gpii.net/browse/GPII-1574>). This would allow node-side test fixtures to wait for the client to indicate that it's ready to continue. Although I have ideas about how to accomplish this using only traditional components, if possible I'd like to handle this using the Nexus <https://github.com/GPII/nexus>. Just to give you an idea, here is a sample sequence of events for a single test: 1. All node fixtures (including a Nexus instance) spin up and signal that they are ready. 2. The node-side fixtures use the Nexus client to create the "entangled" component within the Nexus. 3. A browser instance is opened to a page to be tested. The client-side components are configured to connect to the Nexus and create a client-side "peer" of the existing component. 4. The node-side fixtures step through a sequence of mouse and/or key clicks to trigger an action. 5. The client-side component under test has been configured to update the "entangled" Nexus component's model when it has reached a given state. 6. The Nexus component relays the model change to its "entangled" peers. 7. The node-side fixtures listen for that model change in the Nexus component and fire a node-side event. 8. The next test step listens for that event and continues the test once the client event -> nexus model -> node event relay is complete. That's my first attempt at reconciling the Nexus model relay with the event and listener pattern we use with IoC tests. I'd appreciate feedback about basic fitness, better ways to do this, existing work that might provide a working example, or anything else you care to share. Thanks, Tony
_______________________________________________ Architecture mailing list [email protected] http://lists.gpii.net/mailman/listinfo/architecture
