Also, turning an existing application into a unit test environment isn't useful for our existing use of MobileSpec. I.e. limiting it to CI and running manually by a few devs before releases go out or when working on specific plugin dev.
But this may open tests up to a whole new set of users, where we can ask for test suite results to be attached to JIRA issue reports, etc, without making them jump through hooks. I run library tests a lot more often when its just a matter of "npm test" for example. Maybe it won't end up impactful, but the leg work has been done, and I think we can get there without impacting application size/boot times. -Michal On Mon, May 12, 2014 at 2:49 PM, Michal Mocny <[email protected]> wrote: > Idea: Once we have plugin level hooks, the test-harness plugin can ship > with a hook to install all local plugins' tests by iterating the > plugins/*/tests/ subdirectories to see if plugin.xml is in there and > install if so. This may be much magic. Perhaps it plugin hooks get fed > CLI flags then we can do this only with `cordova prepare --tests` > > -Michal > > > On Mon, May 12, 2014 at 1:36 PM, Andrew Grieve <[email protected]>wrote: > >> Had a look through the README & code. Think it looks might clean! >> >> Only sentiment I have is that I'd like to see our core plugins add tests >> via separate plugins so that the test modules don't end up in shipping >> applications. >> e.g. each cordova plugin could have a subdirectory called "test" that >> contains a plugin.xml that depends on the plugin and also defines a test >> module. >> Reason is that: >> - I'm concerned shipping tests with apps will be an unnecessary >> performance >> hit. Autotests are currently 400kb of JS. >> - I don't think making it easy to turn an application into a unit test >> environment adds much value. >> >> >> >> On Mon, May 12, 2014 at 11:56 AM, Josh Soref <[email protected]> >> wrote: >> >> > Michal Mocny wrote: >> > >Well it *is* a cordova plugin, in the sense that it has a plugin.xml >> and >> > >is >> > >managed using cordova plugin add/rm. It also exports js apis: a list >> of >> > >tests, which you can enable/disable, a way to define auto/manual tests, >> > >and >> > >a way to bootstrap the whole process. It does also ship a full >> > >test-harness application which you can optionally set as your start >> page, >> > >but thats just for convenience. >> > >> > Hrm, ok, then I'm +0/-0 on whichever way. >> > >> > >Anyway, I think its pretty plugin-y, more plugin-y than say >> > >cordova-plugin-console, I think. >> > >> > >> > >However, if we want to reserve "cordova-plugin-*" for device api type >> > >things going forward, I'm okay with changing the name -- its just a >> repo >> > >name, totally not a big deal. The package id users use to install from >> > >registry wouldn't change. >> > >> > >> > >
