Hi, All: Although I've talked a lot about gpii-webdriver in the past, I wanted to change gears for a moment and talk about Testem. Testem and QUnit have been a useful combination for us, with a few limitations. Using only the testem.json configuration file, it is not possible to:
1. Collect client-side code coverage data. 2. Cleanup after testem following its test run. 3. Launch, wait for, and interact with server-side components (for example, by making an AJAX call against a REST endpoint). Although gpii-webdriver provides one way to handle this, I think there are many good uses for Testem, and I often prefer to use it in my own work (it's faster and gives the ability to quickly run tests against a huge range of browsers) . I would also much rather that people use gpii-webdriver for its key strengths (keyboard navigation, complex server/client interactions) rather than using it to work around limitations in Testem. With that in mind, I have been experimenting with using the testem.js configuration file to create a component tied into the Testem lifecycle (see the ticket for details). This approach gives us options to handle each of the above use cases, and IMO it's time to pull the early work out into a gpii-testem micromodule for wider reuse. I wrote up my thoughts in more detail here, with links to my early prototypes: https://issues.gpii.net/browse/GPII-2296 If you use Testem in your own work and are interested in any of the above use cases, please take a little time to review and comment. I need something like this in my current work on the browser-based dataSource, and will likely start fleshing something out tomorrow or Wednesday. Thanks, Tony
_______________________________________________ Architecture mailing list [email protected] http://lists.gpii.net/mailman/listinfo/architecture
