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 <mmo...@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 <na...@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 <mmo...@chromium.org> >> Date: Wednesday, October 30, 2013 10:27 AM >> To: "Naik, Archana" <na...@lab126.com> >> Cc: "dev@cordova.apache.org" <dev@cordova.apache.org>, Michal Mocny < >> mmo...@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 <na...@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" <mmo...@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 <mmo...@chromium.org> >>> >wrote: >>> > >>> >> >>> >> >>> >> >>> >> On Tue, Oct 29, 2013 at 5:29 PM, Bryan Higgins >>> >><br...@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 <drk...@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 <mmo...@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 < >>> >>> > bra...@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 >>> >>><mmo...@chromium.org> >>> >>> > > wrote: >>> >>> > > > >>> >>> > > >> On Fri, Oct 11, 2013 at 9:08 PM, Andrew Grieve < >>> >>> agri...@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 < >>> >>> mmo...@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 < >>> >>> > mmo...@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" < >>> >>> > > bra...@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 < >>> >>> > > >> mmo...@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 < >>> >>> > > >> >> >> mmo...@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 < >>> >>> > > >> >> >> > > > > bra...@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 < >>> >>> > > >> >> >> > > > csantan...@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 < >>> >>> > > >> >> >> > drk...@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 >>> < >>> >>> > > >> >> >> > > > purplecabb...@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 >>> >>> > < >>> >>> > > >> >> >> > > > > > > stevengil...@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 < >>> >>> > > >> >> >> > > > > bows...@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 >>> >>> > > >> >> >> > > > > > > > <csantan...@gmail.com> >>> >>> > > >> >> >> > > > > > > > >>> >>> > > >> >> >> > > > > > > >>> >>> > > >> >> >> > > > > > >>> >>> > > >> >> >> > > > > >>> >>> > > >> >> >> > > > >>> >>> > > >> >> >> > > >>> >>> > > >> >> >> > >>> >>> > > >> >> >> >>> >>> > > >> >> > >>> >>> > > >> >> > >>> >>> > > >> >> >>> >>> > > >> > >>> >>> > > >> > >>> >>> > > >> >>> >>> > > > >>> >>> > > > >>> >>> > > >>> >>> > >>> >>> >>> >> >>> >> >>> >>> >>
