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 <jso...@blackberry.com> 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. > >
