Hi, All: The solution I outlined on the mailing list and in GPII-2296 <https://issues.gpii.net/browse/GPII-2296> has now been submitted for review: https://github.com/GPII/gpii-testem/pull/1
To assist in exercising this in real projects, I have published a dev version to npm <https://www.npmjs.com/package/gpii-testem>. My plan is to exercise gpii-testem further by: 1. Improving the cleanup after tests in the gpii-pouchdb package, as discussed in the latest PR <https://github.com/GPII/gpii-pouchdb/pull/13> . 2. Adding client-side code coverage for Infusion <https://issues.fluidproject.org/browse/FLUID-6135>. I know that Cindy also has a pull that could benefit from the improved cleanup <https://github.com/GPII/universal/pull/503>, I will reach out to her. If you use Testem in your own work and would like to try it, happy to pair or talk you through it. Cheers, Tony On Mon, Feb 20, 2017 at 4:47 PM, Antranig Basman < [email protected]> wrote: > Dear ADTKINS - this is a really excellent idea - looking forward to it! > > On 20/02/2017 09:36, Tony Atkins wrote: > >> 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 >> >> > _______________________________________________ > Architecture mailing list > [email protected] > http://lists.gpii.net/mailman/listinfo/architecture >
_______________________________________________ Architecture mailing list [email protected] http://lists.gpii.net/mailman/listinfo/architecture
