cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: CDV New-Style tests, please try them out!
Date Tue, 13 May 2014 16:38:03 GMT
I love the idea of userland being able to verify their own install of
plugins (and maybe even the core platforms) at some point. Somewhat nerdy
but reminiscent of 'full system diagnostic'. [1]

=)

1] http://en.memory-alpha.org/wiki/Diagnostic_mode


On Mon, May 12, 2014 at 11:55 AM, Michal Mocny <mmocny@chromium.org> wrote:

> 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 <mmocny@chromium.org> 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 <agrieve@chromium.org
> >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 <jsoref@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.
> >> >
> >> >
> >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message