Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 30823101D6 for ; Wed, 30 Oct 2013 14:38:52 +0000 (UTC) Received: (qmail 37111 invoked by uid 500); 30 Oct 2013 14:28:02 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 36943 invoked by uid 500); 30 Oct 2013 14:27:47 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 36654 invoked by uid 99); 30 Oct 2013 14:27:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Oct 2013 14:27:19 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mmocny@google.com designates 209.85.128.178 as permitted sender) Received: from [209.85.128.178] (HELO mail-ve0-f178.google.com) (209.85.128.178) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Oct 2013 14:27:11 +0000 Received: by mail-ve0-f178.google.com with SMTP id db12so1049097veb.9 for ; Wed, 30 Oct 2013 07:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=fPBtymFQ2kJOSDKLKa8qLro93j+F9nzlHccp9hlMJUg=; b=QNNt08jaG6WPG4c//eRZo0krGYvuRzdkjauiyR4vSrSMXBJIq1FoABqxLDbRpZyAHm sm7/qdLG5wLRiCZl5FHIbiTlM77JMIdNX/Dt72IC6EWm24jR2drQfnw49jJiYxcPNBgU 3yMYWXa4XybcMvtlDNZ/0+S5PJ9ApRaGY9qqEgeNAbhF9FoC8EnXzSDf0P+F8f6l+mcJ cBdgDoX3KgEoM7XWoE64a/O8t44N5vgrd9Gb9hCzUJ14PytlCaRSvjUJtHx8tGpCLwLX W1fVieOaU/lStBmFX2SyPLXuDyFIf0CWulmNqJtXabgh1GD+aWcYbd1BwFjzrv0CaCs/ Ozlg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=fPBtymFQ2kJOSDKLKa8qLro93j+F9nzlHccp9hlMJUg=; b=L83uxIjOfCbTq2AP5ByI2nX+j6UTQo9pl30YPb9GfO9dwEQlRGEGwTOjLAKQXOvgYc VnyHRkzsf8J/ZFOQ5Lyg6xqDpsmx3MkDfokeNBLdnhwMvY8JUP2YzSmR9MRJ2JngOKbi /DW1CFglxPO8pv6e+twmJKrio70SLjUQYQwls= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=fPBtymFQ2kJOSDKLKa8qLro93j+F9nzlHccp9hlMJUg=; b=hewnPhV6Aa7sKcn/UEDvIt8MTpGgC2PGKtzKefYT8HsauVOKmUQk4XeniErb3kWImo 8hKZepv+1m80GQsIuxa1RqufHzoG9FIlDtpHbUu4nmYsqYvv4qRAa+fnObFuMMIqhiFM HHpihUmwGmKbHqpYvjOwrcT6ed7Yf+nFgmBosvAZULwnlCFBsJeBGs5RmlP++Naw9Nk0 vnZTETE/nKnxxwfO+P5mqVy7DgvIOruWF/hHqQv6drPLxpDfkVubKYQO22EePMUmY3mO c5YY+YJkA/Zbroa/tRewV9BuBta2a8BJFUDGCaL+fR5b+unQOAlBnC7UsvsZdxtkmqs/ pejA== X-Gm-Message-State: ALoCoQkX4LgzjB07iQkAoaiRnP2uAT6/QIxF7mdA6OlQ95cPBO4RJcIO2HJ5IUxe2Ttf7RxZzHNw4NcErkpCBxjGQ9yupkxDs06wlE1wbxQB7eV20ewjmpELIJT9l4iCAipTiMF4kx/XGtcGKOniBPC9g8v/tf8ImUNdyR7CYUpzfMp3JjzO4qdRNkxSNLQnacdhy6Jfgyso9RTk4DlWLEadY37WhRYc7g== X-Received: by 10.52.98.99 with SMTP id eh3mr1449726vdb.29.1383143198140; Wed, 30 Oct 2013 07:26:38 -0700 (PDT) MIME-Version: 1.0 Sender: mmocny@google.com Received: by 10.52.110.38 with HTTP; Wed, 30 Oct 2013 07:26:18 -0700 (PDT) In-Reply-To: References: From: Michal Mocny Date: Wed, 30 Oct 2013 10:26:18 -0400 X-Google-Sender-Auth: aKwb1aPMqpet-92ctd6hSVEiH8w Message-ID: Subject: Re: mobile-spec and releases: How do we test? To: Michal Mocny Cc: dev Content-Type: multipart/alternative; boundary=20cf307f388800082604e9f61f12 X-Virus-Checked: Checked by ClamAV on apache.org --20cf307f388800082604e9f61f12 Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > > > > On Tue, Oct 29, 2013 at 5:29 PM, Bryan Higgins 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 wrote: >> >> > In spite of that fact that it needs a tooling change, I like the added >> > 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 >> > 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 >> >> > > 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 >> > > tag >> > > >> > > The drawbacks seem to be: >> > > - Not all descendant tags are easy to support for a given mode (ie, >> > > ) >> > > >> > > >> > > Summarizing the options currently discussed in this thread: >> > > >> > > - new tag. Not general enough solution to support >> tests >> > > bundling , so -1 from me for this reason. >> > > - mode="..." attribute for a set of whitelisted tags (, >> > , >> > > ...) >> > > - tag for a set of whitelisted descendant >> > > tags (, , ...) >> > > >> > > The last two options are really functionally equivalent, but given >> that >> > we >> > > opted for tag instead of attribute, I'm also favoring a >> >> > > 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 tags or 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 >> > > 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 >> . 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 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 >> > > >> >> > > > >> >> 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 >> > 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 > > >> > > >> 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: >> > > >> >> >> > > > > > > > > name="Foo >> > > >> >> >> Automated" >> > > >> >> >> > > /> >> > > >> >> >> > > > > > > > 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 >> > > >> >> >> >> > > >> >> >> > > > 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 >> > > >> >> >> > > > > > > > > >> > > >> >> >> > > > > > > > > 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 >> > > >> >> >> > > > > > > > > >> > > >> >> >> > > > > > > > > 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 >> > > >> >> >> > > > > > > > >> > > >> >> >> > > > > > > > > > >> > > >> >> >> > > > > > > > > >> 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 >> > > >> >> >> > > > > > > > > >> > > >> >> >> > > > > > > > > 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 >> > > >> >> >> > > > > > > > >> > > >> >> >> > > > > > > > >> > > >> >> >> > > > > > > >> > > >> >> >> > > > > > >> > > >> >> >> > > > > >> > > >> >> >> > > > >> > > >> >> >> > > >> > > >> >> >> > >> > > >> >> >> >> > > >> >> > >> > > >> >> > >> > > >> >> >> > > >> > >> > > >> > >> > > >> >> > > > >> > > > >> > > >> > >> > > --20cf307f388800082604e9f61f12--