cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: plugin test framework
Date Wed, 25 Jun 2014 00:22:52 GMT
On Tue, Jun 24, 2014 at 6:52 PM, Martin Gonzalez <
martin.c.glez.glez@gmail.com> wrote:

> We've been discussing here in IBM, about add a flag to the CLI to pull the
> tests from the plugin, add them to each platform, prepare, build and
> deploy.
> It would be something like 'cordova run/emulate [platform] --tests'
> The workflow has been discussed and I think that are great ideas.
> Proposal:
> - 'cordova plugin add' it would remain as is.
> -Add the tests to the master branch, and those would be added to the
> project.
> -The plugin framework may be installed manually or can be part of the
> 'cordova run/emulate --tests' workflow.
>
> Workflow:
> - 'cordova prepare' has to change, only if the --tests flag is present it
> would copy the test files.
> - 'cordova build' it would save a copy of config.xml or modify the file to
> replace the content tag: '<content src="index.html" />' by <content
> src="cdvtests/index.html" />, as well as modify plugin.xml of each
> installed plugin to add this tag: '<js-module src="test/tests.js"
> name="tests"></js-module>'
> Options with this one: create a backup of config.xml, modify the file
> adding/replacing the information, save the previous values from the files
> or restore the default config.xml content tag to index.html, it might be
> possible however, not always index.html is the default file in a project.
>
> This behavior it would work only in a temporal way, the idea is not corrupt
> the project at all, meaning that this workflow it will be followed if the
> --tests flag is present in the CLI, it would prepare, build, deploy/emulate
> and at the end it should restore to the previous configuration, meaning
> that config.xml should be restored, as well as each plugin.xml file of each
> installed plugin.
>
> In order to work on this, decisions are required. We have to define how
> it's gonna be:
>
> -The tests on each plugin, where are going to live? on master or cdvtest
> (This branch it may became outdated as Jesse mentioned), I can't find any
> reason to not add them to master.
>
Definitely. cdvtest was never meant to be more than temporary.


> -Backup the plugin.xml and config.xml and then restore them or modify them
> and undo the modifications after run/emulate the app? any thoughts?
>
We can add logic to the tools to do what you want, but we should *not* be
modifying any files on disk to accomplish it.
Config.xml is easy to modify in a one-off since it's a generated file
within platforms/ and is generated on each prepare.
Test files are not though, and to have them not stick around after the
--test run would be pretty tricky to implement robustly.
I think the pitched idea where each plugin repo has a second plugin within
it that contains the tests would be more robust and easier to reason about.
E.g. if you want to add a --test flag to CLI, then have the logic be: for
each installed plugin ID, install $PLUGIN_ID.test (or something along those
lines)
Really, as long as the createmobilespec.js knows to install the test
plugins, I think that would be fine.



> -The flag should work to prepare the project only? and then allow to the
> user/dev to run or emulate or both, emulator/device?
> -'cordova run/emulate --tests cdvtests/index.html' or 'cordova run/emulate
> --tests' ? there is any other useful arguments to improve the workflow?
> -plugin-test-framework, installed manually or automatically?
>
> Also Andrew points are good, improve it to make tests fast, avoid timers,
> identify if its running on the simulator/emulator or not.
>
> Any input, ideas, suggestions about this, it would be great.
>
>
>
> 2014-06-21 10:22 GMT-05:00 Andrew Grieve <agrieve@chromium.org>:
>
> > Just occurred to me it might be a good idea to point out what's
> > not-so-great about our current auto-tests since you guys will be looking
> to
> > refactor them quite a bit. Big things that've come to bug me:
> >
> > - Tests should fail fast instead of timing out when failure callbacks are
> > called. FileTransfer is one case where tests generally fail fast rather
> > than timeout. All this entails is making fail callbacks call the done()
> > callback.
> > - Tests have a lot of copy & paste. Some is okay, but helper functions
> > would go a *long* way for some tests
> > - Tests that don't work on the simulator often time out. Would be better
> if
> > they were skipped when simulator is detected.
> >
> > Thanks again for taking this on, and feel free not to address anything
> I've
> > said. Just wanted to point it out as something that you don't need to go
> > out of your way to keep the same. :)
> >
> >
> > On Fri, Jun 20, 2014 at 12:40 AM, Piotr Zalewa <pzalewa@mozilla.com>
> > wrote:
> >
> > > testing is good, no need to hide it,
> > > it would be good though to not copy it with the rendered app
> > >
> > > Dnia Thu Jun 19 19:11:25 2014 purplecabbage pisze:
> > >
> > >  I think we just lead by example.
> > >>
> > >> Sent from my iPhone
> > >>
> > >>  On Jun 19, 2014, at 6:18 PM, Michal Mocny <mmocny@chromium.org>
> wrote:
> > >>>
> > >>> +1 I agree, this would be awesome.
> > >>>
> > >>> New question, should this merely be the "standard" we adhere to for
> > core
> > >>> plugins, or should we actively make it difficult for plugin devs to
> not
> > >>> ship tests directly with plugins? (Not sure how we could accomplish
> > that,
> > >>> so I hope its just a convention that applies to our work).
> > >>>
> > >>> -Michal
> > >>>
> > >>>
> > >>>  On Thu, Jun 19, 2014 at 7:48 PM, Jesse <purplecabbage@gmail.com>
> > wrote:
> > >>>>
> > >>>> My ultimate would be this:
> > >>>>
> > >>>> cordova create TestFilePlugin
> > >>>> cd TestFilePlugin
> > >>>> cordova platform add android
> > >>>> cordova plugin add
> > >>>>
> > >>>> http://git-wip-us.apache.org/repos/asf/cordova-labs.git#
> > >>>> cdvtest:cordova-plugin-test-framework
> > >>>> cordova plugin add ../cordova-plugin-file/
> > >>>> cordova plugin add ../cordova-plugin-file/test/
> > >>>> cordova run android --start cdvtests/index.html
> > >>>>
> > >>>> Then do this for each plugin, and for each platform
> > >>>> Then do this for all combinations of plugins
> > >>>> ...
> > >>>>
> > >>>> Note the run --start does not yet exist, but this would be awesome!
> > >>>>
> > >>>>
> > >>>> @purplecabbage
> > >>>> risingj.com
> > >>>>
> > >>>>
> > >>>>  On Thu, Jun 19, 2014 at 4:15 PM, Jesse <purplecabbage@gmail.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>> Option a) was what I suggested a ways back, and I still stand by
> it.
> > >>>>> I think it provides the greatest transparency, and simplicity, yet
> it
> > >>>>> is
> > >>>>> still very flexible.
> > >>>>> I don't think it would be hard to accomplish either. This is the
> > small
> > >>>>> re-org I was hinting at, you've already done the hard part.
> > >>>>>
> > >>>>>
> > >>>>> @purplecabbage
> > >>>>> risingj.com
> > >>>>>
> > >>>>>
> > >>>>>  On Thu, Jun 19, 2014 at 3:45 PM, Michal Mocny <
> mmocny@chromium.org>
> > >>>>>>
> > >>>>> wrote:
> > >>>>>
> > >>>>>  Andrew has raised that concern as well.  My gut says that the
> > bundling
> > >>>>>>
> > >>>>> of
> > >>>>
> > >>>>> a
> > >>>>>> few shorts scripts that get parsed but not run as long as they
> don't
> > >>>>>> get
> > >>>>>> require() will not affect applications negatively (there are
> > probably
> > >>>>>>
> > >>>>> many
> > >>>>
> > >>>>> more significant overheads we live with today in cordova) -- but I
> > >>>>>> understand why that may not be useful default.
> > >>>>>>
> > >>>>>> In that case, some ideas: (I recall these were proposed previously
> > but
> > >>>>>>
> > >>>>> not
> > >>>>
> > >>>>> sure by whom)
> > >>>>>> (a) Bundle tests as a plugin-within-the-plugin as such:
> > >>>>>>   myplugin/
> > >>>>>>     - plugin.xml
> > >>>>>>     - src/...
> > >>>>>>     - www/...
> > >>>>>>     - tests/
> > >>>>>>       - plugin.xml
> > >>>>>>       - www/...
> > >>>>>>
> > >>>>>> Which basically means the plugin tests live in the same
> repo/branch,
> > >>>>>> and
> > >>>>>> are fetched as part of "plugin add", but are not moved into
> > platforms/
> > >>>>>>
> > >>>>> on
> > >>>>
> > >>>>> cordova prepare by default, thus don't end up in your application
> > (disk
> > >>>>>> and
> > >>>>>> network are cheap, application startup and size costs are not,
> > >>>>>> right?).
> > >>>>>> Then, to run tests, we basically need to iterate all plugins
> looking
> > >>>>>>
> > >>>>> for a
> > >>>>
> > >>>>> nested tests/plugin.xml, and install those.  This can be added to
> > >>>>>> CLI/Plugman, or just be a CLI hook even.
> > >>>>>>
> > >>>>>> (b) add a <js-test-module> or <js-module type="test"> that is only
> > >>>>>> used
> > >>>>>>
> > >>>>> if
> > >>>>
> > >>>>> you run prepare with --test.  Similar to the above, but I think
> > >>>>>> requires
> > >>>>>> more CLI/config file changes, which I'm not a fan of.
> > >>>>>> (c) Just ship tests as a second plugin in a second repo, and
> > document
> > >>>>>>
> > >>>>> how
> > >>>>
> > >>>>> to install tests.  Can then perhaps have a <dependency type=tests>.
> >  I
> > >>>>>> don't like this as much since its basically back to mobile-spec.
> > >>>>>>
> > >>>>>> WDYT?
> > >>>>>>
> > >>>>>> -Michal
> > >>>>>>
> > >>>>>>
> > >>>>>>  On Thu, Jun 19, 2014 at 4:53 PM, Jesse <purplecabbage@gmail.com>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>> re:
> > >>>>>>>
> > >>>>>>>    Q: What do I do if my plugin tests must have very large
> assets?
> > >>>>>>>    - A: Don't bundle those assets with your plugin. If you can,
> > have
> > >>>>>>>
> > >>>>>> your
> > >>>>>>
> > >>>>>>> ...
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> My concern is I do not want to see tests added to every project
> > that
> > >>>>>>>
> > >>>>>> uses a
> > >>>>>>
> > >>>>>>> plugin, even if the assets are not large, there are implications
> to
> > >>>>>>> including the test framework + all the tests because they get
> > loaded
> > >>>>>>>
> > >>>>>> and
> > >>>>
> > >>>>> processed with all of the plugins and will impact load time even if
> > >>>>>>>
> > >>>>>> never
> > >>>>>>
> > >>>>>>> run.
> > >>>>>>>
> > >>>>>>> 99.9% of the time the plugin tests will be used by us the plugin
> > >>>>>>> developers, and not the people who use the plugin in there apps.
> > >>>>>>>
> > >>>>>>> I agree, having the tester install the test harness plugin
> > dependency
> > >>>>>>> themselves is probably a better option, as I see you have wrapped
> > all
> > >>>>>>>
> > >>>>>> tests
> > >>>>>>
> > >>>>>>> inside a exports.defineAutoTests so we don't have to worry about
> > >>>>>>> describe/it/expects not being defined.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> @purplecabbage
> > >>>>>>> risingj.com
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>  On Thu, Jun 19, 2014 at 1:27 PM, Michal Mocny <
> > mmocny@chromium.org>
> > >>>>>>>>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>  Jesee, the branch is NOT a requirement (I don't think I
> documented
> > >>>>>>>>
> > >>>>>>> it
> > >>>>
> > >>>>> as
> > >>>>>>
> > >>>>>>> such, except in the examples for installing plugins for initial
> > >>>>>>>>
> > >>>>>>> look).
> > >>>>
> > >>>>>  Actually, we should delete those stale branches now that we are
> > >>>>>>>>
> > >>>>>>> moving
> > >>>>>>
> > >>>>>>> up-to-date tests into master.  It was just for early
> > experimentation
> > >>>>>>>>
> > >>>>>>> on
> > >>>>>>
> > >>>>>>> the
> > >>>>>>>
> > >>>>>>>> feature.
> > >>>>>>>>
> > >>>>>>>> Jesse, I'm not seeing the benefit of using plugins-tests.xml or
> > the
> > >>>>>>>> dependency on the test plugin yet, may you elaborate your
> > thoughts?
> > >>>>>>>>
> > >>>>>>>> My hope was that tests are just always installed alongside
> > plugins.
> > >>>>>>>>
> > >>>>>>> If
> > >>>>>>
> > >>>>>>> that is not a good idea for some particular plugin, say because
> it
> > >>>>>>>>
> > >>>>>>> uses
> > >>>>>>
> > >>>>>>> huge assets, I elaborated my answer in the plugin FAQ (
> > >>>>>>>>
> > >>>>>>> https://github.com/apache/cordova-labs/blob/cdvtest/
> > >>>> cordova-plugin-test-framework/README.md#faq
> > >>>>
> > >>>>>  ):
> > >>>>>>>> FAQ
> > >>>>>>>>
> > >>>>>>>>    -
> > >>>>>>>>
> > >>>>>>>>    Q: Should I add org.apache.cordova.test-harness as a
> > >>>>>>>> <dependancy>
> > >>>>>>>>
> > >>>>>>> of
> > >>>>>>
> > >>>>>>> my
> > >>>>>>>
> > >>>>>>>>    plugin?
> > >>>>>>>>    - A: No. The end-user should decide if they want to install
> the
> > >>>>>>>>
> > >>>>>>> test
> > >>>>>>
> > >>>>>>>       harness, not your plugin (most users won't).
> > >>>>>>>>    -
> > >>>>>>>>
> > >>>>>>>>    Q: What do I do if my plugin tests must have very large
> assets?
> > >>>>>>>>    - A: Don't bundle those assets with your plugin. If you can,
> > have
> > >>>>>>>>
> > >>>>>>> your
> > >>>>>>
> > >>>>>>>       tests fail gracefully if those assets don't don't exist
> > >>>>>>>>
> > >>>>>>> (perhaps
> > >>>>
> > >>>>> log
> > >>>>>>>
> > >>>>>>>> a
> > >>>>>>>>       warning, perhaps fail a single asset-checking test, and
> skip
> > >>>>>>>>
> > >>>>>>> the
> > >>>>
> > >>>>>  rest).
> > >>>>>>>>       Then, ideally download those assets automatically into
> local
> > >>>>>>>>
> > >>>>>>> storage
> > >>>>>>>
> > >>>>>>>> the
> > >>>>>>>>       first time tests run. Or create a manual test step to
> > download
> > >>>>>>>> and install
> > >>>>>>>>       assets. As a final alternative, split those test assets
> > into a
> > >>>>>>>> separate
> > >>>>>>>>       plugin, and instruct users to install that plugin to run
> > your
> > >>>>>>>>
> > >>>>>>> full
> > >>>>>>
> > >>>>>>> test
> > >>>>>>>>       suite.
> > >>>>>>>>    -
> > >>>>>>>>
> > >>>>>>>>    Q: Should I ship my app with the test harness plugin
> installed?
> > >>>>>>>>    - A: Not likely. If you want, you can. Then your app could
> even
> > >>>>>>>>
> > >>>>>>> embed
> > >>>>>>
> > >>>>>>> a
> > >>>>>>>
> > >>>>>>>>       link to the test page (cdvtests/index.html) from a help
> > >>>>>>>>
> > >>>>>>> section
> > >>>>
> > >>>>> of
> > >>>>>>
> > >>>>>>>       your app, to give end users a way to run your test suite
> out
> > >>>>>>>>
> > >>>>>>> in
> > >>>>
> > >>>>>  the feild.
> > >>>>>>>>       That may help diagnose causes of issues within your app.
> > >>>>>>>>
> > >>>>>>> Maybe.
> > >>>>
> > >>>>>
> > >>>>>>>>
> > >>>>>>>> =============
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Feel free the debate those answers -- now is certainly the time
> --
> > >>>>>>>>
> > >>>>>>> but I
> > >>>>>>
> > >>>>>>> put a lot of effort to make it super flexible and to not require
> > >>>>>>>>
> > >>>>>>> depending
> > >>>>>>>
> > >>>>>>>> on changes to CLI :P
> > >>>>>>>>
> > >>>>>>>> -Michal
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Thu, Jun 19, 2014 at 3:11 PM, Jesse <purplecabbage@gmail.com
> >
> > >>>>>>>>
> > >>>>>>> wrote:
> > >>>>>>
> > >>>>>>>
> > >>>>>>>>  Sorry I missed providing feedback on this earlier ...
> > >>>>>>>>> Having a deeper look at this, I am not feeling great about the
> > >>>>>>>>>
> > >>>>>>>> extra
> > >>>>
> > >>>>>  requirement that every plugin have an additional branch.
> > >>>>>>>>>
> > >>>>>>>>> Several concerns arise :
> > >>>>>>>>> - test branch can be out of sync with master
> > >>>>>>>>> - how do we test a specific version?
> > >>>>>>>>> - tests are not immediately visible when looking at master
> > >>>>>>>>> - differing versions of plugin.xml depending on the branch
> > >>>>>>>>>
> > >>>>>>>>> The majority of the work has been done (thanks Michal!), and
> > >>>>>>>>>
> > >>>>>>>> mostly
> > >>>>
> > >>>>> any
> > >>>>>>
> > >>>>>>> suggestions I make will just require moving code and changing a
> > >>>>>>>>>
> > >>>>>>>> few
> > >>>>
> > >>>>>  conventions.
> > >>>>>>>>>
> > >>>>>>>>> What if we? :
> > >>>>>>>>> 1. add a plugin-test.xml file which has the exact format of
> > >>>>>>>>>
> > >>>>>>>> plugin.xml
> > >>>>>>
> > >>>>>>> 2. keep tests/ and plugin-test.xml file in master branch
> > >>>>>>>>> 3. have plugman/cli support an additional flag --test so we can
> > >>>>>>>>>
> > >>>>>>>> install
> > >>>>>>
> > >>>>>>> like this:
> > >>>>>>>>> cordova plugin add
> > >>>>>>>>>
> http://git-wip-us.apache.org/repos/asf/cordova-plugin-device.git
> > >>>>>>>>>
> > >>>>>>>> --test
> > >>>>>>>
> > >>>>>>>> This would mean that in addition to processing the plugin.xml of
> > >>>>>>>>>
> > >>>>>>>> the
> > >>>>
> > >>>>>  plugin, we would also process the plugin-test.xml file ( identical
> > >>>>>>>>> processing logic )
> > >>>>>>>>> 4. have all plugin-test.xml files declare a dependency on
> > >>>>>>>>> cordova-plugin-test-framework
> > >>>>>>>>>
> > >>>>>>>>> The above suggestions could also be used in conjuction with the
> > >>>>>>>>>
> > >>>>>>>> cordova
> > >>>>>>
> > >>>>>>> run
> > >>>>>>>>
> > >>>>>>>>> --tests platform mentioned by Michal, but without the need to
> > >>>>>>>>>
> > >>>>>>>> manage
> > >>>>
> > >>>>> the
> > >>>>>>>
> > >>>>>>>> switching of branches.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> @purplecabbage
> > >>>>>>>>> risingj.com
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Tue, Jun 17, 2014 at 2:16 PM, Michal Mocny <
> > >>>>>>>>>
> > >>>>>>>> mmocny@chromium.org>
> > >>>>
> > >>>>>  wrote:
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>  Piotr: Actually I'm not sure how running tests in the harness
> > >>>>>>>>>>
> > >>>>>>>>> would
> > >>>>>>
> > >>>>>>> work,
> > >>>>>>>>
> > >>>>>>>>> since the path to the resource may be different.  However, in
> > >>>>>>>>>>
> > >>>>>>>>> general,
> > >>>>>>>
> > >>>>>>>> with
> > >>>>>>>>>
> > >>>>>>>>>> development using the harness you aren't making any changes to
> > >>>>>>>>>>
> > >>>>>>>>> plugins.
> > >>>>>>>
> > >>>>>>>> The whole point is for app developers who want to modify only
> > >>>>>>>>>>
> > >>>>>>>>> web
> > >>>>
> > >>>>>  application bits and not deal with native compiles.
> > >>>>>>>>>>
> > >>>>>>>>>> In theory the app harness could support working on the
> > >>>>>>>>>>
> > >>>>>>>>> js-modules
> > >>>>
> > >>>>> of
> > >>>>>>
> > >>>>>>>  plugins, but that sounds like a really niche idea.  I'd not be
> > >>>>>>>>>>
> > >>>>>>>>> opposed
> > >>>>>>>
> > >>>>>>>> to
> > >>>>>>>>
> > >>>>>>>>> someone working on it but I'm not sure you'll have luck finding
> > >>>>>>>>>>
> > >>>>>>>>> volunteers.
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> -Michal
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Tue, Jun 17, 2014 at 5:13 PM, Michal Mocny <
> > >>>>>>>>>>
> > >>>>>>>>> mmocny@chromium.org>
> > >>>>>>
> > >>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>  At the time I went through my design iterations I just didn't
> > >>>>>>>>>>>
> > >>>>>>>>>> want
> > >>>>>>
> > >>>>>>> to
> > >>>>>>>
> > >>>>>>>>  necessarily depend on cordova tooling changes / documentation.
> > >>>>>>>>>>>
> > >>>>>>>>>> In
> > >>>>>>
> > >>>>>>> other
> > >>>>>>>>>
> > >>>>>>>>>> words, someone else may have a different strategy for
> > >>>>>>>>>>>
> > >>>>>>>>>> testing..
> > >>>>
> > >>>>>
> > >>>>>>>>>>> My personal opinion would be have the test plugin ship with a
> > >>>>>>>>>>>
> > >>>>>>>>>> plugin
> > >>>>>>>
> > >>>>>>>> hook
> > >>>>>>>>>
> > >>>>>>>>>> (those are in, right? or at least on their way), that will
> > >>>>>>>>>>>
> > >>>>>>>>>> automatically
> > >>>>>>>>>
> > >>>>>>>>>> update the start page if you pass a flag to run command.  Ie,
> > >>>>>>>>>>>
> > >>>>>>>>>> in an
> > >>>>>>
> > >>>>>>> ideal
> > >>>>>>>>>
> > >>>>>>>>>> world:  `cordova run --tests` runs a plugin hook passing in
> > >>>>>>>>>>>
> > >>>>>>>>>> --tests
> > >>>>>>
> > >>>>>>> flag
> > >>>>>>>>>
> > >>>>>>>>>> which changes the start page, in a way that isn't overwritten
> > >>>>>>>>>>>
> > >>>>>>>>>> by
> > >>>>
> > >>>>> the
> > >>>>>>>
> > >>>>>>>>  top-level config.xml.
> > >>>>>>>>>>>
> > >>>>>>>>>>> My 2 cents, since I don't want "our way" of testing mobile
> > >>>>>>>>>>>
> > >>>>>>>>>> spec
> > >>>>
> > >>>>> to
> > >>>>>>
> > >>>>>>> be
> > >>>>>>>
> > >>>>>>>> "the
> > >>>>>>>>>>
> > >>>>>>>>>>> only way" to test.   Frameworks and opinions on testing
> > >>>>>>>>>>>
> > >>>>>>>>>> change.
> > >>>>
> > >>>>>
> > >>>>>>>>>>> -Michal
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Tue, Jun 17, 2014 at 4:33 PM, Piotr Zalewa <
> > >>>>>>>>>>>
> > >>>>>>>>>> pzalewa@mozilla.com
> > >>>>>>
> > >>>>>>>
> > >>>>>>>>  wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>  One thing more - it would be great if user could create a
> > >>>>>>>>>>>>
> > >>>>>>>>>>> test
> > >>>>
> > >>>>> using
> > >>>>>>>
> > >>>>>>>> test
> > >>>>>>>>>>
> > >>>>>>>>>>> harness app as well. Is it also considered?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Dnia Tue Jun 17 13:27:22 2014 Martin Gonzalez pisze:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> It would be a nice to have in the cli, aimed to just setup
> > >>>>>>>>>>>>
> > >>>>>>>>>>> the
> > >>>>
> > >>>>>  right
> > >>>>>>>>
> > >>>>>>>>> path
> > >>>>>>>>>>
> > >>>>>>>>>>> in the config.xml, maybe along with an another argument to
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> build,
> > >>>>>>
> > >>>>>>>  run/emulate as well.
> > >>>>>>>>>>>>> It sounds great.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> 2014-06-17 15:21 GMT-05:00 Piotr Zalewa <
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> pzalewa@mozilla.com
> > >>>>
> > >>>>> :
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>>>>>>> Thanks Martin,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Has it been considered to create a separate command
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>> "testrun" or
> > >>>>>>
> > >>>>>>>  similar
> > >>>>>>>>>>
> > >>>>>>>>>>>  which would remove the need to edit the config.xml?
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Dnia Tue Jun 17 11:58:33 2014 Michal Mocny pisze:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>   Martin, thanks for posting those links.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> And I'll look into the INFRA tickets I need to file to
> set
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> up a
> > >>>>>>
> > >>>>>>> repo
> > >>>>>>>>>
> > >>>>>>>>>>  for
> > >>>>>>>>>>>>>>> that plugin, since its ready to come out of labs.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Tue, Jun 17, 2014 at 2:06 PM, Martin Gonzalez <
> > >>>>>>>>>>>>>>> martin.c.glez.glez@gmail.com> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>   This is the Cordova Plugin Test Framework readme.md,
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> you
> > >>>>
> > >>>>> can
> > >>>>>>
> > >>>>>>> catch
> > >>>>>>>>>
> > >>>>>>>>>>  up
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>  with
> > >>>>>>>>>>>>>>>> the functionality by reading some of the content:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Repository:
> > >>>>>>>>>>>>>>>> https://github.com/apache/cordova-labs
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Docs:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > https://github.com/apache/cordova-labs/blob/master/README.md
> > >>>>>>
> > >>>>>>>
> > >>>>>>>>>>>>>>>> https://github.com/apache/cordova-labs/blob/cdvtest/
> > >>>>>>>>>>>>>>>> cordova-plugin-test-framework/README.md
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> 2014-06-17 12:56 GMT-05:00 Piotr Zalewa <
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> pzalewa@mozilla.com
> > >>>>>>
> > >>>>>>> :
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>>>>>>>   a documentation explaining how it's gonna work
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Dnia Tue Jun 17 10:51:58 2014 Michal Mocny pisze:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>    What do you mean?
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On Tue, Jun 17, 2014 at 1:50 PM, Piotr Zalewa <
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> pzalewa@mozilla.com>
> > >>>>>>>>>>
> > >>>>>>>>>>>  wrote:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>    Is there any predev document?
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>  Dnia Mon Jun 16 18:30:46 2014 Andrew Grieve pisze:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>     Yeah, really exciting. Thanks for taking this on.
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>  On Mon, Jun 16, 2014 at 3:42 PM, Michal Mocny <
> > >>>>>>>>>>>>>>>>>>>> mmocny@chromium.org>
> > >>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>     Fantastic!
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> I'll try to keep an eye out on the PR's, and please
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> ping
> > >>>>>>
> > >>>>>>> me
> > >>>>>>>
> > >>>>>>>> if
> > >>>>>>>>>
> > >>>>>>>>>>   you
> > >>>>>>>>>>>>>>>>>>>>> would
> > >>>>>>>>>>>>>>>>>>>>> like any help.
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> -Michal
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> On Mon, Jun 16, 2014 at 3:25 PM, Marcel Kinard <
> > >>>>>>>>>>>>>>>>>>>>> cmarcelk@gmail.com>
> > >>>>>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>     Hi, after some discussions here with IBM
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> management,
> > >>>>>>
> > >>>>>>> we’re
> > >>>>>>>>>
> > >>>>>>>>>>   going
> > >>>>>>>>>>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>   bring
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>  in a couple extra interns for a week to jumpstart
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>  the
> > >>>>
> > >>>>>  migration
> > >>>>>>>>>>
> > >>>>>>>>>>>   of
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> tests out of mobile-spec into the new plugin test
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> framework.
> > >>>>>>
> > >>>>>>> Staci
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>>>>>>>>  Cooper
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>  will be leading this effort, and Martin Gonzalez
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>  will
> > >>>>
> > >>>>> be a
> > >>>>>>>
> > >>>>>>>> part
> > >>>>>>>>>>
> > >>>>>>>>>>>   of
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> it.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>  So if you see a bunch of pull requests, this is what it
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> is
> > >>>>>>
> > >>>>>>> for.
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> We’ll
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> get
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>  the interns to submit an ICLA asap.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>     --
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Piotr Zalewa
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> Mozilla
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>    --
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Piotr Zalewa
> > >>>>>>>>>>>>>>>>> Mozilla
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>> Regards,
> > >>>>>>>>>>>>>>>> Martin Gonzalez
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Piotr Zalewa
> > >>>>>>>>>>>>>> Mozilla
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>> --
> > >>>>>>>>>>>> Piotr Zalewa
> > >>>>>>>>>>>> Mozilla
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>
> > > --
> > > Piotr Zalewa
> > > Mozilla
> > >
> >
>
>
>
> --
> Regards,
> Martin Gonzalez
>

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