Hi Tony, Thanks for summarizing the conversation so far and thoughts on next steps.
> 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. A minor clarification in case anyone else ever needs to do achieve something similar. Originally I was waiting for an element's aria-expanded attribute [1] to be reported as false before proceeding. Alan had a hunch that polling for size [2] would resolve the race condition. That proved to be reliable and not just waiting for a specific time period to elapse. Avtar [1] https://github.com/fluid-project/infusion/blob/master/src/components/overviewPanel/js/OverviewPanel.js#L190 [2] https://github.com/avtar/infusion/blob/1d6c980bec69e12e94ed0fdec8f933e3f14340d8/tests/demo-tests/axe-example.js#L12-L29 > On Feb 13, 2017, at 8:36 AM, Tony Atkins <[email protected]> wrote: > > Hi, All: > > Antranig, Alan, Avtar and I have been having a side conversation about a > specific use of 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: > • You want to test keyboard navigation between components. > • You need to interrogate both server side and client-side components > in a single test sequence. > • You need to test navigation between pages or browser history > manipulation. > • 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). 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. Just to > give you an idea, here is a sample sequence of events for a single test: > • All node fixtures (including a Nexus instance) spin up and signal > that they are ready. > • The node-side fixtures use the Nexus client to create the "entangled" > component within the Nexus. > • 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. > • The node-side fixtures step through a sequence of mouse and/or key > clicks to trigger an action. > • The client-side component under test has been configured to update > the "entangled" Nexus component's model when it has reached a given state. > • The Nexus component relays the model change to its "entangled" peers. > • The node-side fixtures listen for that model change in the Nexus > component and fire a node-side event. > • 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 _______________________________________________ Architecture mailing list [email protected] http://lists.gpii.net/mailman/listinfo/architecture
