cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: mobile-spec and releases: How do we test?
Date Thu, 31 Oct 2013 15:05:16 GMT
I ported the contacts plugin [1] to the new style and I found the
process to be more or less straightforward. I also kept the eval in
there but there might be a better way ?

[1] http://goo.gl/uhnwtz

On Wed, Oct 30, 2013 at 3:42 PM, Michal Mocny <mmocny@chromium.org> wrote:
> Sadly, we are approaching an in-between time of moving the mobile-spec
> tests out of the app and into plugins.  We are still investigating the best
> way to do this without disruption.
>
> For what its worth: several plugins now have a 'cdvtest' branch which
> supplies new-style tests ripped out of mobile-spec.  If you are having
> issues cleaning up the old style tests, take a look at the new ones (or try
> porting yourself).
>
> I'm going to write up a doc with the summary of the state of testing within
> a day or so given the results of this week to make it easier for you (and
> others) to pick up.
>
> -Michal
>
>
> On Wed, Oct 30, 2013 at 1:54 PM, Naik, Archana <naika@lab126.com> wrote:
>
>>  Thanks Michal. You answered my questions.
>>
>>  More to elaborate on my question: I am testing amazon-fireos
>> port(platform) with all plug-ins using mobile-spec. I am seeing some
>> failures in 3.1.0 version because of test cases timing out. I am pretty new
>> to cordova and still in learning phase. :) I am trying to understand these
>> failures. Interestingly they pass on 3.0.x version.
>>
>>  Archana
>>
>>
>>   From: Michal Mocny <mmocny@chromium.org>
>> Date: Wednesday, October 30, 2013 10:27 AM
>> To: "Naik, Archana" <naika@lab126.com>
>> Cc: "dev@cordova.apache.org" <dev@cordova.apache.org>, Michal Mocny <
>> mmocny@chromium.org>
>>
>> Subject: Re: mobile-spec and releases: How do we test?
>>
>>   May you clarify?
>>
>>  Right now, there is no formal way to test plugins, we are trying to
>> invent that way now.  Check out cordova-labs repo's cdvtest branch for a
>> sample app & plugin to track progress.
>>
>>  Jasmine is hosted in that sample app, but plugins will not directly
>> know/care.  Any testing framework which is api-compatible should work.  In
>> practice, I'm not sure how compatible they all are, so it may very well be
>> limited to jasmine -- but it does mean you can make local modifications
>> such as our CI is doing to create a custom test reporter.
>>
>>  -Michal
>>
>>
>> On Wed, Oct 30, 2013 at 12:57 PM, Naik, Archana <naika@lab126.com> wrote:
>>
>>> Hi, Guys
>>>
>>> While on this topic, I have a question: how do I test individual plug-in?
>>> Where is the this jasmine version specified?
>>>
>>> Thanks
>>> Archana
>>>
>>> On 10/30/13 7:26 AM, "Michal Mocny" <mmocny@chromium.org> wrote:
>>>
>>> >Here are some links to jasmine-2 docs since its a hard time finding them:
>>> >
>>> >http://jasmine.github.io/2.0/introduction.html
>>> >
>>> >https://github.com/pivotal/jasmine/blob/master/release_notes/20rc5.md
>>> >
>>> >
>>> >On Wed, Oct 30, 2013 at 10:16 AM, Michal Mocny <mmocny@chromium.org>
>>> >wrote:
>>> >
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Oct 29, 2013 at 5:29 PM, Bryan Higgins
>>> >><bryan@bryanhiggins.net>wrote:
>>> >>
>>> >>> I just converted geolocation to the new test style [1]
>>> >>>
>>> >>> I'm happy with the process overall, and I find the jasmine 2 tests are
>>> >>> more
>>> >>> succinct.
>>> >>>
>>> >>> There are a few things worth noting:
>>> >>> - I kept the eval code in. At google today, it was discussed that this
>>> >>>may
>>> >>> not be the best approach.
>>> >>> - Jasmine 2: You must hit at least one expect statement or the test
>>> >>>will
>>> >>> timeout even though done was called.
>>> >>>
>>> >>
>>> >> We could file a bug (I ran into it during setup once too), but really,
>>> >> what is the worth of a test if there are no expect clauses?
>>> >>
>>> >>
>>> >>> - I did not remove the manual test page [2]. It would be great if we
>>> >>>had a
>>> >>> convention for importing these. (ie test harness looks for a page at
>>> >>> www/test/plugin-id.html and adds a link to it if it exists)
>>> >>>
>>> >>
>>> >> I'm going to work on a solution for this today.  The thought is that
>>> the
>>> >> plugin has a single module that can define all auto/manual tests, and
>>> >>the
>>> >> test-harness choses which to display where.
>>> >>
>>> >>
>>> >>>
>>> >>> [1]
>>> >>>
>>> >>>
>>> >>>
>>> https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-geolocation.git
>>> >>>;a=commit;h=075850a460d8171a04809cf6317fb4c4ef998603
>>> >>> [2]
>>> >>>
>>> >>>
>>> >>>
>>> https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-geolocation.git
>>>
>>> >>>;a=blob;f=test/manual.html;h=6ec2eed03e18c2efaa8710094d60930bb32227ba;hb
>>> >>>=459a01c888801e8dfa2a688d25483bb48c46d8e2
>>> >>>
>>> >>>
>>> >>> On Tue, Oct 15, 2013 at 12:50 PM, David Kemp <drkemp@chromium.org>
>>> >>>wrote:
>>> >>>
>>> >>> > In spite of that fact that it needs a tooling change, I like the
>>> >>>added
>>> >>> > <mode> tag / prepare steps.
>>> >>> > The tooling change should be small and it means no runtime impact on
>>> >>> apps.
>>> >>> >
>>> >>> > I love the approach - a very positive step to cleaning up testing.
>>> >>> >
>>> >>> > David Kemp
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > On Tue, Oct 15, 2013 at 12:18 PM, Michal Mocny <mmocny@chromium.org
>>> >
>>> >>> > wrote:
>>> >>> >
>>> >>> > > Braden, you're right, good catch.
>>> >>> > >
>>> >>> > > Discussing locally how we could support "prepare --mode=..." in
>>> the
>>> >>> most
>>> >>> > > generalized form, we remembered an old suggestion to just support
>>> >>> <mode>
>>> >>> > > tags.
>>> >>> > >
>>> >>> > > The benefits seem to be:
>>> >>> > > - No need to add custom tag-prefix/attributes for the combinations
>>> >>>of
>>> >>> > > js-module mode=, asset mode=, etc etc
>>> >>> > > - More visually apparent when reading a plugin.xml file, akin to
>>> >>> > > <platforms> tag
>>> >>> > >
>>> >>> > > The drawbacks seem to be:
>>> >>> > > - Not all descendant tags are easy to support for a given mode
>>> (ie,
>>> >>> > > <dependency>)
>>> >>> > >
>>> >>> > >
>>> >>> > > Summarizing the options currently discussed in this thread:
>>> >>> > >
>>> >>> > > - new <js-test-module> tag.  Not general enough solution to
>>> support
>>> >>> tests
>>> >>> > > bundling <assets>, so -1 from me for this reason.
>>> >>> > > - mode="..." attribute for a set of whitelisted tags (<js-module>,
>>> >>> > <asset>,
>>> >>> > > ...)
>>> >>> > > - <mode name="..."> tag for a set of whitelisted descendant
>>> >>> > > tags (<js-module>, <asset>, ...)
>>> >>> > >
>>> >>> > > The last two options are really functionally equivalent, but given
>>> >>> that
>>> >>> > we
>>> >>> > > opted for <platform> tag instead of attribute, I'm also favoring a
>>> >>> <mode>
>>> >>> > > tag.
>>> >>> > >
>>> >>> > > -Michal
>>> >>> > >
>>> >>> > >
>>> >>> > > On Tue, Oct 15, 2013 at 11:43 AM, Braden Shepherdson <
>>> >>> > braden@chromium.org
>>> >>> > > >wrote:
>>> >>> > >
>>> >>> > > > It's not true that adding these tests only creates larger
>>> >>>binaries.
>>> >>> > They
>>> >>> > > > will be fetched and parsed by the plugin loader code at app
>>> >>>startup
>>> >>> > time.
>>> >>> > > > It goes through the list of all plugins in cordova_plugins.js
>>> and
>>> >>> loads
>>> >>> > > > them all. That parses them, and runs the outermost layer, which
>>> >>>is
>>> >>> the
>>> >>> > > > wrapping function function(require, module, exports) { ... }. So
>>> >>> there
>>> >>> > is
>>> >>> > > > still runtime memory and CPU impact.
>>> >>> > > >
>>> >>> > > > I support <js-test-module> tags or <js-module ... test> or
>>> >>>whatever.
>>> >>> > > > Similarly, prepare for tests. I realize we want to avoid tooling
>>> >>> > support,
>>> >>> > > > but I think tooling support is a lesser evil than production
>>> >>> > performance
>>> >>> > > > impact.
>>> >>> > > >
>>> >>> > > > Overall approach makes me happy.
>>> >>> > > >
>>> >>> > > > Braden
>>> >>> > > >
>>> >>> > > >
>>> >>> > > > On Fri, Oct 11, 2013 at 9:43 PM, Michal Mocny
>>> >>><mmocny@chromium.org>
>>> >>> > > wrote:
>>> >>> > > >
>>> >>> > > >> On Fri, Oct 11, 2013 at 9:08 PM, Andrew Grieve <
>>> >>> agrieve@chromium.org>
>>> >>> > > >> wrote:
>>> >>> > > >>
>>> >>> > > >> > The eval of the jasmine interface deserves mention. Is the
>>> >>> > motivation
>>> >>> > > >> > there that tests can choose to use another testing framework?
>>> >>> That's
>>> >>> > > why
>>> >>> > > >> > you don't just make jasmine functions globals?
>>> >>> > > >> >
>>> >>> > > >>
>>> >>> > > >> I was hoping the plugins would need to depend on anything but
>>> >>> CDVTest,
>>> >>> > > and
>>> >>> > > >> not expect any globals.  I guess, though, that CDVTest still
>>> >>> expects
>>> >>> > the
>>> >>> > > >> app to provide to a test framework and some other stuff, so in
>>> >>>the
>>> >>> end
>>> >>> > > its
>>> >>> > > >> no different.  I was hedging on being able to update CDVTest in
>>> >>>the
>>> >>> > > future
>>> >>> > > >> for whatever we need, and all 3rdparty plugins would not need
>>> >>> > updating.
>>> >>> > > >>  eval() could be used to do all sorts of clever things if we
>>> >>> needed..
>>> >>> > > >>
>>> >>> > > >>
>>> >>> > > >> >
>>> >>> > > >> > One nit pick just from reading your email is that this will
>>> >>>cause
>>> >>> > the
>>> >>> > > >> test
>>> >>> > > >> > js-modules to be injected into apps that use the plugins. I
>>> >>>think
>>> >>> > > >> probably
>>> >>> > > >> > we will want to update the tools to recognize a
>>> >>> <js-test-module>. We
>>> >>> > > >> > *could* work around it by adding the tests to new plugins
>>> that
>>> >>> > depend
>>> >>> > > on
>>> >>> > > >> > the thing they are testing, but I think changing the tools
>>> >>>would
>>> >>> be
>>> >>> > > >> nicer.
>>> >>> > > >> >
>>> >>> > > >>
>>> >>> > > >> I also mentioned splitting tests into second plugin but thats
>>> >>> overkill
>>> >>> > > >> except in extreme circumstances.  Note that the tests aren't
>>> >>> actually
>>> >>> > > >> loaded unless you require them, so its just a matter of larger
>>> >>> > binaries
>>> >>> > > >> which could be filtered out manually.
>>> >>> > > >>
>>> >>> > > >> My person preference would be to support conditional build
>>> >>>types,
>>> >>> > which
>>> >>> > > >> have come up before.  ie, cordova prepare debug, cordova
>>> prepare
>>> >>> > > release,
>>> >>> > > >> cordova prepare test -- and plugin.xml could specify a
>>> different
>>> >>> set
>>> >>> > of
>>> >>> > > >> js-module for either.
>>> >>> > > >>
>>> >>> > > >> A specific <js-test-module> would be fine, but isnt "0 new
>>> >>> tooling".
>>> >>> > > >>
>>> >>> > > >> Also, I forgot to mention, but we do need to add support for
>>> >>> getting
>>> >>> > the
>>> >>> > > >> full list of plugins installed, which should be trivial to add
>>> >>>to
>>> >>> > > >> modulemapper (maybe there  is already a way to reach in, but I
>>> >>> don't
>>> >>> > > think
>>> >>> > > >> we have a documented api for it).
>>> >>> > > >>
>>> >>> > > >>
>>> >>> > > >> > Another nit is that it would be nice if the CordovaTests app
>>> >>> didn't
>>> >>> > > >> depend
>>> >>> > > >> > on any plugins. e.g., don't have it depend on device plugin.
>>> >>> > > >> >
>>> >>> > > >>
>>> >>> > > >> CordovaTests doesn't explicitly depend on device plugin, except
>>> >>> that
>>> >>> > at
>>> >>> > > >> the
>>> >>> > > >> moment I have it printing the same info that MobileSpec does at
>>> >>> > startup.
>>> >>> > > >>  This could be wrapped in a try{}catch in case the require
>>> >>>fails,
>>> >>> but
>>> >>> > > its
>>> >>> > > >> good info to have in the common case.
>>> >>> > > >>
>>> >>> > > >>
>>> >>> > > >> >
>>> >>> > > >> > Overall, really like the approach!
>>> >>> > > >> >
>>> >>> > > >>
>>> >>> > > >> Thanks!
>>> >>> > > >>
>>> >>> > > >>
>>> >>> > > >> >
>>> >>> > > >> >
>>> >>> > > >> > On Fri, Oct 11, 2013 at 5:17 PM, Michal Mocny <
>>> >>> mmocny@chromium.org>
>>> >>> > > >> wrote:
>>> >>> > > >> >
>>> >>> > > >> >> TLDR; I've implemented a plugin testing strategy that
>>> >>>requires 0
>>> >>> > new
>>> >>> > > >> >> tooling features, can support non-core plugins, and
>>> hopefully
>>> >>> even
>>> >>> > > >> support
>>> >>> > > >> >> a variety of methods for running/reporting the test results.
>>> >>>  Super
>>> >>> > > >> alpha
>>> >>> > > >> >> preview, but take a look if you like the direction!
>>> >>> > > >> >>
>>> >>> > > >> >>
>>> >>> > > >> >> NEW: CDVTest Plugin: https://github.com/mmocny/CDVTest
>>> >>> > > >> >>
>>> >>> > > >> >> NEW: CordovaTest App:
>>> https://github.com/mmocny/CordovaTests
>>> >>> > > >> >>
>>> >>> > > >> >> UPDATED: Converted three existing plugins to this "new
>>> >>>style".
>>> >>> >  Code
>>> >>> > > >> is on
>>> >>> > > >> >> feature branches of respective repos (cdvtest branch):
>>> >>> > > >> >> org.apache.cordova.device
>>> >>> > > >> >> org.apache.cordova.device-motion
>>> >>> > > >> >> org.chromium.storage
>>> >>> > > >> >> (must clone locally, switch to branch, and plugin add from
>>> >>>local
>>> >>> > > path)
>>> >>> > > >> >>
>>> >>> > > >> >>
>>> >>> > > >> >> Now, any plugin that wants to join in on the fun needs to
>>> >>> provide a
>>> >>> > > >> >> <js-module
>>> >>> > > >> >> src="..." name="test" /> and use this template:
>>> >>> > > >> >>
>>> >>> > > >> >> exports.init = function() {
>>> >>> > > >> >>
>>> >>> > > >> >>
>>> >>> > > >>
>>> >>> > >
>>> >>>
>>>
>>> >>>eval(require('org.apache.cordova.test.test').injectJasmineInterface(this
>>> >>>,
>>> >>> > > >> >> 'this'));
>>> >>> > > >> >>
>>> >>> > > >> >>   // TESTS GO HERE
>>> >>> > > >> >>   describe(..., function() {
>>> >>> > > >> >>     it(...);
>>> >>> > > >> >>   });
>>> >>> > > >> >> };
>>> >>> > > >> >> (The eval is optional but super useful; it will inject the
>>> >>> jasmine
>>> >>> > > >> >> interface into your scope, so you don't have to type
>>> >>> > > jasmine.describe,
>>> >>> > > >> >> jasmine.it, etc.  Not sure of any cleaner way to do this.)
>>> >>> > > >> >>
>>> >>> > > >> >>
>>> >>> > > >> >> STEPS:
>>> >>> > > >> >> 1. create a new cordova project
>>> >>> > > >> >> 2. import the CordovaTest app into your www
>>> >>> > > >> >> 3. add any or all of the above plugins
>>> >>> > > >> >> 4. give it a run, and try out the auto tests (all pass on
>>> >>>ipad,
>>> >>> > some
>>> >>> > > >> still
>>> >>> > > >> >> fail on android)
>>> >>> > > >> >>
>>> >>> > > >> >> Lots of work left to do, but hopefully good enough to whet
>>> >>>your
>>> >>> > > >> appetite.
>>> >>> > > >> >>
>>> >>> > > >> >> One thing to note, I've attempted to make CDVTest and plugin
>>> >>> tests
>>> >>> > > >> unaware
>>> >>> > > >> >> of the specific jasmine version the app is hosting (so that
>>> >>>it
>>> >>> can
>>> >>> > be
>>> >>> > > >> >> swapped without changing all plugins), but it must support
>>> >>>the
>>> >>> new
>>> >>> > > >> style
>>> >>> > > >> >> interface for async tests (ie, accept a done callback).
>>> >>>This is
>>> >>> > the
>>> >>> > > >> style
>>> >>> > > >> >> that node-jasmine uses, mocha uses, and jasmine-2.0 is going
>>> >>>to
>>> >>> use
>>> >>> > > >> (I'm
>>> >>> > > >> >> using jasmine 2.0 rc3).  This means that core plugin tests
>>> >>> require
>>> >>> > > some
>>> >>> > > >> >> code transformations, but the net effect is cleaner tests
>>> and
>>> >>> more
>>> >>> > > >> common
>>> >>> > > >> >> style with our node tools' tests.
>>> >>> > > >> >>
>>> >>> > > >> >> Manual tests are not implemented yet.
>>> >>> > > >> >>
>>> >>> > > >> >> -Michal
>>> >>> > > >> >>
>>> >>> > > >> >> On Fri, Oct 11, 2013 at 12:54 PM, Michal Mocny <
>>> >>> > mmocny@chromium.org>
>>> >>> > > >> >> wrote:
>>> >>> > > >> >>
>>> >>> > > >> >> > I'm throwing something together right now, actually.  I'll
>>> >>> post
>>> >>> > my
>>> >>> > > >> >> current
>>> >>> > > >> >> > progress today so you can take a look.
>>> >>> > > >> >> >
>>> >>> > > >> >> >
>>> >>> > > >> >> > On Fri, Oct 11, 2013 at 12:41 PM, Brian LeRoux <
>>> b@brian.io>
>>> >>> > wrote:
>>> >>> > > >> >> >
>>> >>> > > >> >> >> Sorry keep meaning to respond. I like Michal's first step
>>> >>>but
>>> >>> > > >> growing
>>> >>> > > >> >> to a
>>> >>> > > >> >> >> full suite of tools. Are you currently tackling this
>>> >>>Braden?
>>> >>> I
>>> >>> > > feel
>>> >>> > > >> >> like
>>> >>> > > >> >> >> it
>>> >>> > > >> >> >> is related to the Medic stuff and maybe we should throw
>>> >>>one
>>> >>> of
>>> >>> > our
>>> >>> > > >> >> guys on
>>> >>> > > >> >> >> the problem fully.
>>> >>> > > >> >> >>
>>> >>> > > >> >> >>
>>> >>> > > >> >> >> On Sep 27, 2013 5:10 PM, "Braden Shepherdson" <
>>> >>> > > braden@chromium.org>
>>> >>> > > >> >> >> wrote:
>>> >>> > > >> >> >>
>>> >>> > > >> >> >> > Which one?
>>> >>> > > >> >> >> >
>>> >>> > > >> >> >> >
>>> >>> > > >> >> >> > On Fri, Sep 27, 2013 at 10:09 AM, Brian LeRoux
>>> >>><b@brian.io
>>> >>> >
>>> >>> > > >> wrote:
>>> >>> > > >> >> >> >
>>> >>> > > >> >> >> > > I really like your proposal as a starting point. Very
>>> >>> simple
>>> >>> > > but
>>> >>> > > >> >> would
>>> >>> > > >> >> >> > > allow for in-app testing as well as on the cmd line
>>> if
>>> >>> we so
>>> >>> > > >> wish.
>>> >>> > > >> >> >> > >
>>> >>> > > >> >> >> > >
>>> >>> > > >> >> >> > > On Fri, Sep 27, 2013 at 3:28 PM, Michal Mocny <
>>> >>> > > >> mmocny@chromium.org
>>> >>> > > >> >> >
>>> >>> > > >> >> >> > wrote:
>>> >>> > > >> >> >> > >
>>> >>> > > >> >> >> > > > I was looking over some old emails from this list
>>> on
>>> >>> > plugin
>>> >>> > > >> >> testing,
>>> >>> > > >> >> >> > and
>>> >>> > > >> >> >> > > an
>>> >>> > > >> >> >> > > > idea that was proposed way back was to ship plugin
>>> >>> tests
>>> >>> > as
>>> >>> > > a
>>> >>> > > >> >> second
>>> >>> > > >> >> >> > > > plugin.  That way, you can chose to install tests,
>>> >>>or
>>> >>> not,
>>> >>> > > and
>>> >>> > > >> >> know
>>> >>> > > >> >> >> > > > explicitly if they are being copied into your final
>>> >>> > project.
>>> >>> > > >> >> >> > > >
>>> >>> > > >> >> >> > > > An alternative would be to support build targets a
>>> >>>la
>>> >>> > > >> >> >> "release/debug"
>>> >>> > > >> >> >> > and
>>> >>> > > >> >> >> > > > have target-specific plugin.xml tags (assets,
>>> >>> js-modules,
>>> >>> > > >> >> >> > source-file..).
>>> >>> > > >> >> >> > > >
>>> >>> > > >> >> >> > > > -Michal
>>> >>> > > >> >> >> > > >
>>> >>> > > >> >> >> > > >
>>> >>> > > >> >> >> > > > On Fri, Sep 27, 2013 at 4:52 AM, Brian LeRoux <
>>> >>> b@brian.io
>>> >>> > >
>>> >>> > > >> >> wrote:
>>> >>> > > >> >> >> > > >
>>> >>> > > >> >> >> > > > > I think this is basically what we've been
>>> >>>proposing
>>> >>> for
>>> >>> > a
>>> >>> > > >> while
>>> >>> > > >> >> >> now.
>>> >>> > > >> >> >> > > > >
>>> >>> > > >> >> >> > > > >
>>> >>> > > >> >> >> > > > > On Thu, Sep 26, 2013 at 8:29 PM, Michal Mocny <
>>> >>> > > >> >> >> mmocny@chromium.org>
>>> >>> > > >> >> >> > > > wrote:
>>> >>> > > >> >> >> > > > >
>>> >>> > > >> >> >> > > > > > I would suggest perhaps a simpler approach,
>>> >>>which
>>> >>> > > doesn't
>>> >>> > > >> add
>>> >>> > > >> >> >> > > anything
>>> >>> > > >> >> >> > > > > new
>>> >>> > > >> >> >> > > > > > to cordova-cli/plugman:
>>> >>> > > >> >> >> > > > > >
>>> >>> > > >> >> >> > > > > > - Each plugin ships with a "tests" js-module,
>>> >>>and
>>> >>> we
>>> >>> > > >> >> document a
>>> >>> > > >> >> >> > > > > convention
>>> >>> > > >> >> >> > > > > > of where they should live, and what signature
>>> it
>>> >>> > should
>>> >>> > > >> have
>>> >>> > > >> >> >> (i.e.,
>>> >>> > > >> >> >> > > > > >
>>> >>>cordova.require('plugin.name.Tests').forEach(...)
>>> >>> ).
>>> >>> > > >> >> >> > > > > >   - Will need a common way to describe/report
>>> >>> results
>>> >>> > > >> (others
>>> >>> > > >> >> >> have
>>> >>> > > >> >> >> > > > > > mentioned TAP).
>>> >>> > > >> >> >> > > > > > - Any app is free to run those plugin tests in
>>> >>>any
>>> >>> > which
>>> >>> > > >> way,
>>> >>> > > >> >> >> but
>>> >>> > > >> >> >> > we
>>> >>> > > >> >> >> > > > > ship a
>>> >>> > > >> >> >> > > > > > mobile-spec app which is one opinionated way to
>>> >>>do
>>> >>> so.
>>> >>> > > >> >> >> > > > > >   - It attempts to require the test module for
>>> >>>each
>>> >>> > > >> installed
>>> >>> > > >> >> >> > plugin,
>>> >>> > > >> >> >> > > > > runs
>>> >>> > > >> >> >> > > > > > them, and aggregates results.
>>> >>> > > >> >> >> > > > > >   - It could report results to some shared
>>> >>>server,
>>> >>> > allow
>>> >>> > > >> >> >> toggling
>>> >>> > > >> >> >> > of
>>> >>> > > >> >> >> > > > > tests,
>>> >>> > > >> >> >> > > > > > etc, but no plugin should know or care about
>>> >>>those
>>> >>> > > >> features.
>>> >>> > > >> >> >> > > > > >
>>> >>> > > >> >> >> > > > > > Using that as a generic base:
>>> >>> > > >> >> >> > > > > >
>>> >>> > > >> >> >> > > > > > - We ship a "CDVTests" (or whatever) plugin
>>> >>>which
>>> >>> has
>>> >>> > a
>>> >>> > > >> >> bunch of
>>> >>> > > >> >> >> > > > library
>>> >>> > > >> >> >> > > > > > code for creating tests, and plugins can use it
>>> >>>to
>>> >>> > > >> register
>>> >>> > > >> >> >> their
>>> >>> > > >> >> >> > > > tests.
>>> >>> > > >> >> >> > > > > > - This makes it easier to register manual tests
>>> >>>in
>>> >>> a
>>> >>> > > >> common
>>> >>> > > >> >> >> format
>>> >>> > > >> >> >> > > for
>>> >>> > > >> >> >> > > > > core
>>> >>> > > >> >> >> > > > > > plugins, and prevents code duplication for core
>>> >>> auto
>>> >>> > > >> tests.
>>> >>> > > >> >> >> > > > > > - External plugins can chose to use our testing
>>> >>> > library,
>>> >>> > > >> or
>>> >>> > > >> >> not.
>>> >>> > > >> >> >> > > > > >
>>> >>> > > >> >> >> > > > > > -Michal
>>> >>> > > >> >> >> > > > > >
>>> >>> > > >> >> >> > > > > >
>>> >>> > > >> >> >> > > > > > On Thu, Sep 26, 2013 at 10:34 AM, Braden
>>> >>> Shepherdson <
>>> >>> > > >> >> >> > > > > braden@chromium.org
>>> >>> > > >> >> >> > > > > > >wrote:
>>> >>> > > >> >> >> > > > > >
>>> >>> > > >> >> >> > > > > > > Here's an off-the-top-of-my-head sketch of
>>> >>>how we
>>> >>> > > might
>>> >>> > > >> do
>>> >>> > > >> >> >> > Voltron
>>> >>> > > >> >> >> > > > > tests:
>>> >>> > > >> >> >> > > > > > >
>>> >>> > > >> >> >> > > > > > > - Add a tag to plugin.xml that names each
>>> test
>>> >>> file:
>>> >>> > > >> >> >> > > > > > >     <test type="automatic" src="spec/foo.js"
>>> >>> > name="Foo
>>> >>> > > >> >> >> Automated"
>>> >>> > > >> >> >> > > />
>>> >>> > > >> >> >> > > > > > >     <test type="manual" src="spec/bar.js"
>>> >>> name="Foo
>>> >>> > > >> >> Manual" />
>>> >>> > > >> >> >> > > > > > > - Add a new command, cordova test (maybe
>>> >>> > > prepare-test),
>>> >>> > > >> >> that:
>>> >>> > > >> >> >> > > > > > >     - Ignores the top-level www.
>>> >>> > > >> >> >> > > > > > >     - Instead copies in a basic testing
>>> >>> index.html
>>> >>> > > >> similar
>>> >>> > > >> >> to
>>> >>> > > >> >> >> the
>>> >>> > > >> >> >> > > > > current
>>> >>> > > >> >> >> > > > > > > mobile-spec's
>>> >>> > > >> >> >> > > > > > >     - That index reads a file akin to
>>> >>> > > cordova_plugins.js
>>> >>> > > >> >> >> > > > > > (cordova_tests.js,
>>> >>> > > >> >> >> > > > > > > maybe?) generated by the CLI, containing the
>>> >>>info
>>> >>> > from
>>> >>> > > >> the
>>> >>> > > >> >> >> <test>
>>> >>> > > >> >> >> > > > tags.
>>> >>> > > >> >> >> > > > > > >     - It has navigation similar to the
>>> current
>>> >>> > > >> mobile-spec,
>>> >>> > > >> >> >> with
>>> >>> > > >> >> >> > > > > buttons
>>> >>> > > >> >> >> > > > > > > for the automatic and manual sections. Auto
>>> >>>has
>>> >>> > "All"
>>> >>> > > >> and
>>> >>> > > >> >> then
>>> >>> > > >> >> >> > each
>>> >>> > > >> >> >> > > > > > module,
>>> >>> > > >> >> >> > > > > > > manual just has the list of modules.
>>> >>> > > >> >> >> > > > > > >
>>> >>> > > >> >> >> > > > > > > Thoughts?
>>> >>> > > >> >> >> > > > > > >
>>> >>> > > >> >> >> > > > > > > Braden
>>> >>> > > >> >> >> > > > > > >
>>> >>> > > >> >> >> > > > > > >
>>> >>> > > >> >> >> > > > > > > On Thu, Sep 26, 2013 at 6:33 AM, Carlos
>>> >>>Santana <
>>> >>> > > >> >> >> > > > csantana23@gmail.com
>>> >>> > > >> >> >> > > > > > > >wrote:
>>> >>> > > >> >> >> > > > > > >
>>> >>> > > >> >> >> > > > > > > > I like the idea can we call mobilespec now
>>> >>> > > >> >> cordova-voltron
>>> >>> > > >> >> >> and
>>> >>> > > >> >> >> > be
>>> >>> > > >> >> >> > > > DRY
>>> >>> > > >> >> >> > > > > > and
>>> >>> > > >> >> >> > > > > > > > use the tests form the plugins.
>>> >>> > > >> >> >> > > > > > > >
>>> >>> > > >> >> >> > > > > > > > Voltron by itself creates an App that tests
>>> >>> only
>>> >>> > > core,
>>> >>> > > >> >> but
>>> >>> > > >> >> >> as
>>> >>> > > >> >> >> > you
>>> >>> > > >> >> >> > > > > > > > use plugman to add plugins to voltron it
>>> has
>>> >>> more
>>> >>> > > test
>>> >>> > > >> >> >> cases.
>>> >>> > > >> >> >> > > > > > > >
>>> >>> > > >> >> >> > > > > > > > It would not be a bad idea to enhance
>>> >>> plugin.xml
>>> >>> > in
>>> >>> > > >> the
>>> >>> > > >> >> >> future
>>> >>> > > >> >> >> > to
>>> >>> > > >> >> >> > > > > > include
>>> >>> > > >> >> >> > > > > > > > information about testing (i.e. Directory
>>> >>> > containing
>>> >>> > > >> >> tests
>>> >>> > > >> >> >> > files,
>>> >>> > > >> >> >> > > > > test
>>> >>> > > >> >> >> > > > > > > > command, etc..)
>>> >>> > > >> >> >> > > > > > > >
>>> >>> > > >> >> >> > > > > > > > --Carlos
>>> >>> > > >> >> >> > > > > > > >
>>> >>> > > >> >> >> > > > > > > > On Thursday, September 26, 2013, Anis KADRI
>>> >>> wrote:
>>> >>> > > >> >> >> > > > > > > >
>>> >>> > > >> >> >> > > > > > > > > What's the challenge of having us use the
>>> >>> tests
>>> >>> > > that
>>> >>> > > >> >> come
>>> >>> > > >> >> >> > with
>>> >>> > > >> >> >> > > > the
>>> >>> > > >> >> >> > > > > > > > > individual plugins ?
>>> >>> > > >> >> >> > > > > > > > >
>>> >>> > > >> >> >> > > > > > > > > On Thu, Sep 26, 2013 at 8:13 AM, David
>>> >>>Kemp <
>>> >>> > > >> >> >> > drkemp@google.com
>>> >>> > > >> >> >> > > > > > > > <javascript:;>>
>>> >>> > > >> >> >> > > > > > > > > wrote:
>>> >>> > > >> >> >> > > > > > > > > > Currently, the automated test system
>>> >>>that
>>> >>> we
>>> >>> > > have
>>> >>> > > >> >> >> running
>>> >>> > > >> >> >> > > > > (derived
>>> >>> > > >> >> >> > > > > > > from
>>> >>> > > >> >> >> > > > > > > > > > Medic) uses only the mobilespec tests.
>>> >>>It
>>> >>> does
>>> >>> > > not
>>> >>> > > >> >> yet
>>> >>> > > >> >> >> use
>>> >>> > > >> >> >> > > > tests
>>> >>> > > >> >> >> > > > > > > > > collected
>>> >>> > > >> >> >> > > > > > > > > > from the plugins. Its been talked
>>> about,
>>> >>> but
>>> >>> > not
>>> >>> > > >> gone
>>> >>> > > >> >> >> > > anywhere.
>>> >>> > > >> >> >> > > > > > > > > >
>>> >>> > > >> >> >> > > > > > > > > > David Kemp
>>> >>> > > >> >> >> > > > > > > > > >
>>> >>> > > >> >> >> > > > > > > > > >
>>> >>> > > >> >> >> > > > > > > > > > On Wed, Sep 25, 2013 at 7:58 PM, Jesse
>>> <
>>> >>> > > >> >> >> > > > purplecabbage@gmail.com
>>> >>> > > >> >> >> > > > > > > > <javascript:;>>
>>> >>> > > >> >> >> > > > > > > > > wrote:
>>> >>> > > >> >> >> > > > > > > > > >
>>> >>> > > >> >> >> > > > > > > > > >> Yeah, I have pushed some changes to
>>> >>> > > mobile-spec,
>>> >>> > > >> and
>>> >>> > > >> >> >> when
>>> >>> > > >> >> >> > I
>>> >>> > > >> >> >> > > > did
>>> >>> > > >> >> >> > > > > I
>>> >>> > > >> >> >> > > > > > > also
>>> >>> > > >> >> >> > > > > > > > > >> copied the tests into the plugin
>>> >>>involved.
>>> >>> > > >> >> >> > > > > > > > > >> Until we get the magic test runner
>>> >>> > happening, I
>>> >>> > > >> >> think
>>> >>> > > >> >> >> we
>>> >>> > > >> >> >> > > just
>>> >>> > > >> >> >> > > > > keep
>>> >>> > > >> >> >> > > > > > > > > >> duplicating.
>>> >>> > > >> >> >> > > > > > > > > >>
>>> >>> > > >> >> >> > > > > > > > > >> @purplecabbage
>>> >>> > > >> >> >> > > > > > > > > >> risingj.com
>>> >>> > > >> >> >> > > > > > > > > >>
>>> >>> > > >> >> >> > > > > > > > > >>
>>> >>> > > >> >> >> > > > > > > > > >> On Wed, Sep 25, 2013 at 4:38 PM,
>>> Steven
>>> >>> Gill
>>> >>> > <
>>> >>> > > >> >> >> > > > > > > stevengill97@gmail.com
>>> >>> > > >> >> >> > > > > > > > <javascript:;>
>>> >>> > > >> >> >> > > > > > > > > >
>>> >>> > > >> >> >> > > > > > > > > >> wrote:
>>> >>> > > >> >> >> > > > > > > > > >>
>>> >>> > > >> >> >> > > > > > > > > >> > We copied over tests into plugins
>>> >>>when
>>> >>> we
>>> >>> > > first
>>> >>> > > >> >> broke
>>> >>> > > >> >> >> > them
>>> >>> > > >> >> >> > > > > out,
>>> >>> > > >> >> >> > > > > > > but
>>> >>> > > >> >> >> > > > > > > > I
>>> >>> > > >> >> >> > > > > > > > > >> don't
>>> >>> > > >> >> >> > > > > > > > > >> > believe they have been updated.
>>> >>> > > >> >> >> > > > > > > > > >> >
>>> >>> > > >> >> >> > > > > > > > > >> > I would say for now to just add the
>>> >>> tests
>>> >>> > to
>>> >>> > > >> >> mobile
>>> >>> > > >> >> >> > spec,
>>> >>> > > >> >> >> > > > and
>>> >>> > > >> >> >> > > > > > > > > possibly in
>>> >>> > > >> >> >> > > > > > > > > >> > the future we go all voltron to
>>> build
>>> >>> > mobile
>>> >>> > > >> spec
>>> >>> > > >> >> and
>>> >>> > > >> >> >> > keep
>>> >>> > > >> >> >> > > > > tests
>>> >>> > > >> >> >> > > > > > > > with
>>> >>> > > >> >> >> > > > > > > > > >> their
>>> >>> > > >> >> >> > > > > > > > > >> > corresponding plugins.
>>> >>> > > >> >> >> > > > > > > > > >> >
>>> >>> > > >> >> >> > > > > > > > > >> >
>>> >>> > > >> >> >> > > > > > > > > >> > On Wed, Sep 25, 2013 at 4:22 PM, Joe
>>> >>> > Bowser <
>>> >>> > > >> >> >> > > > > bowserj@gmail.com
>>> >>> > > >> >> >> > > > > > > > <javascript:;>>
>>> >>> > > >> >> >> > > > > > > > > wrote:
>>> >>> > > >> >> >> > > > > > > > > >> >
>>> >>> > > >> >> >> > > > > > > > > >> > > Hey
>>> >>> > > >> >> >> > > > > > > > > >> > >
>>> >>> > > >> >> >> > > > > > > > > >> > > Right now, I'm working on a weird
>>> >>>file
>>> >>> > > issue
>>> >>> > > >> >> that
>>> >>> > > >> >> >> > > requires
>>> >>> > > >> >> >> > > > > me
>>> >>> > > >> >> >> > > > > > to
>>> >>> > > >> >> >> > > > > > > > > >> > > update mobile-spec, but I'm
>>> >>>wondering
>>> >>> > where
>>> >>> > > >> the
>>> >>> > > >> >> >> tests
>>> >>> > > >> >> >> > > > should
>>> >>> > > >> >> >> > > > > > > live.
>>> >>> > > >> >> >> > > > > > > > > >> > > Should it all keep living in
>>> >>> mobile-spec,
>>> >>> > > or
>>> >>> > > >> is
>>> >>> > > >> >> it
>>> >>> > > >> >> >> > with
>>> >>> > > >> >> >> > > > the
>>> >>> > > >> >> >> > > > > > > > plugins.
>>> >>> > > >> >> >> > > > > > > > > >> > > And if it's with the plugins, will
>>> >>> there
>>> >>> > be
>>> >>> > > >> >> >> scripts to
>>> >>> > > >> >> >> > > > > > assemble
>>> >>> > > >> >> >> > > > > > > > > >> > > mobile-spec all Voltron style?
>>> >>> > > >> >> >> > > > > > > > > >> > >
>>> >>> > > >> >> >> > > > > > > > > >> > > This came up earlier, but I
>>> haven't
>>> >>> found
>>> >>> > > any
>>> >>> > > >> >> fix
>>> >>> > > >> >> >> that
>>> >>> > > >> >> >> > > > > needed
>>> >>> > > >> >> >> > > > > > a
>>> >>> > > >> >> >> > > > > > > > > >> > > mobile-spec test.  (Many that need
>>> >>> native
>>> >>> > > >> >> testing,
>>> >>> > > >> >> >> > like
>>> >>> > > >> >> >> > > > > > > recursive
>>> >>> > > >> >> >> > > > > > > > > file
>>> >>> > > >> >> >> > > > > > > > > >> > > copy, etc).  Any thoughts?
>>> >>> > > >> >> >> > > > > > > > > >> > >
>>> >>> > > >> >> >> > > > > > > > > >> > > Joe
>>> >>> > > >> >> >> > > > > > > > > >> > >
>>> >>> > > >> >> >> > > > > > > > > >> >
>>> >>> > > >> >> >> > > > > > > > > >>
>>> >>> > > >> >> >> > > > > > > > >
>>> >>> > > >> >> >> > > > > > > >
>>> >>> > > >> >> >> > > > > > > >
>>> >>> > > >> >> >> > > > > > > > --
>>> >>> > > >> >> >> > > > > > > > Carlos Santana
>>> >>> > > >> >> >> > > > > > > > <csantana23@gmail.com>
>>> >>> > > >> >> >> > > > > > > >
>>> >>> > > >> >> >> > > > > > >
>>> >>> > > >> >> >> > > > > >
>>> >>> > > >> >> >> > > > >
>>> >>> > > >> >> >> > > >
>>> >>> > > >> >> >> > >
>>> >>> > > >> >> >> >
>>> >>> > > >> >> >>
>>> >>> > > >> >> >
>>> >>> > > >> >> >
>>> >>> > > >> >>
>>> >>> > > >> >
>>> >>> > > >> >
>>> >>> > > >>
>>> >>> > > >
>>> >>> > > >
>>> >>> > >
>>> >>> >
>>> >>>
>>> >>
>>> >>
>>>
>>>
>>

Mime
View raw message