cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: mobile-spec and releases: How do we test?
Date Wed, 30 Oct 2013 19:42:45 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message