cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gonzalez <martin.c.glez.g...@gmail.com>
Subject Re: plugin test framework
Date Tue, 24 Jun 2014 22:52:10 GMT
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.
-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?
-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