subject:"test"

Github user purplecabbage commented on a diff in the pull request:

https://github.com/apache/cordova-plugin-camera/pull/34#discussion_r13982226
  
--- Diff: plugin.xml ---
@@ -33,6 +33,9 @@
 js-module src=www/CameraConstants.js name=Camera
 clobbers target=Camera /
 /js-module
+   
+   js-module src=test/tests.js name=tests
--- End diff --

Doesn't this mean that the tests are going to be added to every project 
that uses this plugin?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-camera pull request: CB- 6958. Port camera test to ...

Github user purplecabbage commented on a diff in the pull request:

https://github.com/apache/cordova-plugin-camera/pull/34#discussion_r13982279
  
--- Diff: plugin.xml ---
@@ -202,6 +205,7 @@
 !-- windows8 --
 platform name=windows8
 
+dependency id=org.apache.cordova.file /
--- End diff --

Is this a mistake? We just removed this dependency ... 
06ecc91fd1430bf3261990315e7e6361a6bc5cad


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-camera pull request: CB- 6958. Port camera test to ...

2014-06-19 Thread javierbb31

Github user javierbb31 commented on a diff in the pull request:

https://github.com/apache/cordova-plugin-camera/pull/34#discussion_r13983869
  
--- Diff: plugin.xml ---
@@ -202,6 +205,7 @@
 !-- windows8 --
 platform name=windows8
 
+dependency id=org.apache.cordova.file /
--- End diff --

Yes, this is a mistake, I started to work on that 3 days ago. I will fix it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-camera pull request: CB- 6958. Port camera test to ...

2014-06-19 Thread javierbb31

Github user javierbb31 commented on a diff in the pull request:

https://github.com/apache/cordova-plugin-camera/pull/34#discussion_r13984170
  
--- Diff: plugin.xml ---
@@ -33,6 +33,9 @@
 js-module src=www/CameraConstants.js name=Camera
 clobbers target=Camera /
 /js-module
+   
+   js-module src=test/tests.js name=tests
--- End diff --

Yes, it means that the tests are going to be added on every project that 
uses this plugin, however, this PR it should have to be addressed to another 
branch(cdvtest, as it is for the plugin-device, which already has the tests for 
the plugin-test framework.
https://github.com/apache/cordova-plugin-device/tree/cdvtest
Are you able to create the branch cdvtest for this repository?
Is there any way to correctly address this PR to that branch once created?

Thanks for the feedback.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: plugin test framework

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 mmo...@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 mmo...@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 pzal...@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 pzal...@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.g...@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 pzal...@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 
 pzal...@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 
  mmo...@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 
  cmarc...@gmail.com
  wrote:
 
  Hi, after some discussions here with IBM management, we’re

[GitHub] cordova-plugin-camera pull request: CB- 6958. Port camera test to ...

Github user purplecabbage commented on the pull request:


https://github.com/apache/cordova-plugin-camera/pull/34#issuecomment-46609974
  
I've started a conversation on this, before we go and create `test` 
branches for all ~20ish plugins.
http://markmail.org/message/576yxsj6xvg6rycw




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: plugin test framework

2014-06-19 Thread Michal Mocny

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 purplecabb...@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 mmo...@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 mmo...@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

Re: plugin test framework

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 mmo...@chromium.org wrote:

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.
-

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 purplecabb...@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.

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.

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 mmo...@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

Re: plugin test framework

2014-06-19 Thread Michal Mocny

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 purplecabb...@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
...

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.

@purplecabbage
risingj.com

On Thu, Jun 19, 2014 at 1:27 PM, Michal Mocny mmo...@chromium.org wrote:

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 purplecabb...@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

Re: plugin test framework

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 mmo...@chromium.org wrote:

WDYT?

-Michal

On Thu, Jun 19, 2014 at 4:53 PM, Jesse purplecabb...@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 mmo...@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

Re: plugin test framework

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 purplecabb...@gmail.com wrote:

@purplecabbage
risingj.com

On Thu, Jun 19, 2014 at 3:45 PM, Michal Mocny mmo...@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.

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.

WDYT?

-Michal

On Thu, Jun 19, 2014 at 4:53 PM, Jesse purplecabb...@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 mmo...@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).
-

Re: plugin test framework

2014-06-19 Thread Michal Mocny

+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 purplecabb...@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 purplecabb...@gmail.com wrote:

@purplecabbage
risingj.com

On Thu, Jun 19, 2014 at 3:45 PM, Michal Mocny mmo...@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 purplecabb...@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 mmo...@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

Re: plugin test framework

I think we just lead by example.

Sent from my iPhone

On Jun 19, 2014, at 6:18 PM, Michal Mocny mmo...@chromium.org wrote:

+1 I agree, this would be awesome.

-Michal

On Thu, Jun 19, 2014 at 7:48 PM, Jesse purplecabb...@gmail.com wrote:

My ultimate would be this:

cordova create TestFilePlugin
cd TestFilePlugin
cordova platform add android
cordova plugin add

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 purplecabb...@gmail.com wrote:

@purplecabbage
risingj.com

On Thu, Jun 19, 2014 at 3:45 PM, Michal Mocny mmo...@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 purplecabb...@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 mmo...@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

Re: plugin test framework

2014-06-19 Thread Piotr Zalewa

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 mmo...@chromium.org wrote:

+1 I agree, this would be awesome.

-Michal

On Thu, Jun 19, 2014 at 7:48 PM, Jesse purplecabb...@gmail.com wrote:

My ultimate would be this:

cordova create TestFilePlugin
cd TestFilePlugin
cordova platform add android
cordova plugin add

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 purplecabb...@gmail.com wrote:

@purplecabbage
risingj.com

On Thu, Jun 19, 2014 at 3:45 PM, Michal Mocny mmo...@chromium.org

wrote:

Andrew has raised that concern as well. My gut says that the bundling

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/

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

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 purplecabb...@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 mmo...@chromium.org

wrote:

Jesee, the branch is NOT a requirement (I don't think I documented

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

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.

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

[GitHub] cordova-mobile-spec pull request: CB-6928: Add 304 response test

2014-06-18 Thread jpuerto

GitHub user jpuerto opened a pull request:

https://github.com/apache/cordova-mobile-spec/pull/71

CB-6928: Add 304 response test



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jpuerto/cordova-mobile-spec master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-mobile-spec/pull/71.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #71


commit 4f78beb5c55e5d02a0abc589db116e24220d52b2
Author: Javier Puerto javier.pue...@becompany.ch
Date:   2014-06-19T00:59:22Z

CB-6928: Add 304 response test




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: plugin test framework


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 mmo...@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 cmarc...@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

Re: plugin test framework

What do you mean?


On Tue, Jun 17, 2014 at 1:50 PM, Piotr Zalewa pzal...@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 mmo...@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 cmarc...@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

Re: plugin test framework


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 pzal...@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 mmo...@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 cmarc...@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

Re: plugin test framework

2014-06-17 Thread Martin Gonzalez

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 pzal...@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 pzal...@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 mmo...@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 cmarc...@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

Re: plugin test framework

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.g...@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 pzal...@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 pzal...@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 mmo...@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 cmarc...@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

Re: plugin test framework


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.g...@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 pzal...@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 pzal...@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 mmo...@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 cmarc...@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

Re: plugin test framework

2014-06-17 Thread Martin Gonzalez

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 pzal...@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.g...@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 pzal...@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 pzal...@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 mmo...@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 cmarc...@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




-- 
Regards,
Martin Gonzalez

Re: plugin test framework

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 pzal...@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.g...@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 pzal...@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 pzal...@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 mmo...@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 cmarc...@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

Re: plugin test framework

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 pzal...@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 pzal...@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.g...@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 pzal...@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 pzal...@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 mmo...@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 
 cmarc...@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

Re: plugin test framework