Hi, All: Just to close the loop following my conversation with Antranig, the basic process is sound, but the last few steps can be simplified:
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. Although I'll still need a client-side event->model pipeline (steps 5 and 6), on the node side, the IoC test framework can listen directly for model changes using the "changeEvent" approach referenced in our docs <http://docs.fluidproject.org/infusion/development/IoCTestingFramework.html#supported-fixture-records>. So step 7 becomes: 7. The next IoC test sequence step listens for the relevant model changeEvent in the nexus component and continues the tests. We also discussed a key point, which is that I need to wrap the Nexus component such that I can refer to the Nexus model material using IoC references in non-Nexus contexts (such as IoC tests). Antranig pointed out his latest approach to doing this <https://github.com/amb26/fluid-authoring/blob/FLUID-4884/src/client/js/ComponentGraphRemote.js#L93>. I am currently studying this and thinking over how to apply it to my work. I would expect that as more of us start transitioning to using Nexus components at least partially, a pattern like that would eventually be factored into one or more utilities we can use more widely. For now, if you're already using the Nexus and want to collaborate on the areas of overlap, please chime in here. If there's enough interest we can put together at least a couple of shorting working meetings and divide up the work. Cheers, Tony On Mon, Feb 13, 2017 at 2:36 PM, 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 <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
