cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Naik, Archana" <na...@lab126.com>
Subject Re: mobile-spec and releases: How do we test?
Date Wed, 30 Oct 2013 17:54:04 GMT
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<mailto:mmocny@chromium.org>>
Date: Wednesday, October 30, 2013 10:27 AM
To: "Naik, Archana" <naika@lab126.com<mailto:naika@lab126.com>>
Cc: "dev@cordova.apache.org<mailto:dev@cordova.apache.org>" <dev@cordova.apache.org<mailto:dev@cordova.apache.org>>, Michal Mocny <mmocny@chromium.org<mailto: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<mailto: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<mailto: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<mailto:mmocny@chromium.org>>
>wrote:
>
>>
>>
>>
>> On Tue, Oct 29, 2013 at 5:29 PM, Bryan Higgins
>><bryan@bryanhiggins.net<mailto: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<mailto: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<mailto: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<mailto: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<mailto:mmocny@chromium.org>>
>>> > > wrote:
>>> > > >
>>> > > >> On Fri, Oct 11, 2013 at 9:08 PM, Andrew Grieve <
>>> agrieve@chromium.org<mailto: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<mailto: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<http://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<mailto: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<mailto: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<mailto:braden@chromium.org>>
>>> > > >> >> >> wrote:
>>> > > >> >> >>
>>> > > >> >> >> > Which one?
>>> > > >> >> >> >
>>> > > >> >> >> >
>>> > > >> >> >> > On Fri, Sep 27, 2013 at 10:09 AM, Brian LeRoux
>>><b@brian.io<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<http://risingj.com>
>>> > > >> >> >> > > > > > > > > >>
>>> > > >> >> >> > > > > > > > > >>
>>> > > >> >> >> > > > > > > > > >> On Wed, Sep 25, 2013 at 4:38 PM, Steven
>>> Gill
>>> > <
>>> > > >> >> >> > > > > > > stevengill97@gmail.com<mailto: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<mailto: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<mailto:csantana23@gmail.com>>
>>> > > >> >> >> > > > > > > >
>>> > > >> >> >> > > > > > >
>>> > > >> >> >> > > > > >
>>> > > >> >> >> > > > >
>>> > > >> >> >> > > >
>>> > > >> >> >> > >
>>> > > >> >> >> >
>>> > > >> >> >>
>>> > > >> >> >
>>> > > >> >> >
>>> > > >> >>
>>> > > >> >
>>> > > >> >
>>> > > >>
>>> > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>



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