> First pass: a test/ directory with one or more \w+.test.js files? Tools
> can find the .test.js files and run them automagically?
Yes.
> Up to the author to decide which test framework to run with (jasmine,
> their own, qunit, whatever). All necessary supporting files to be included
> under ./t
First pass: a test/ directory with one or more \w+.test.js files? Tools
can find the .test.js files and run them automagically?
Up to the author to decide which test framework to run with (jasmine,
their own, qunit, whatever). All necessary supporting files to be included
under ./test as well?
Wh
Yes, each plugin should be responsible for its own tests. This is something
that we should practice with the core plugins and encourage with
third-party plugins.
I'm still playing catch up, but this is something that must be added to the
plugin spec IMO.
Michael
On Thu, Feb 7, 2013 at 12:48 PM,
This is definitely what I had envisioned as well..
On 2/7/13 11:13 AM, "Andrew Grieve" wrote:
>If someone wants to lead the charge on this angle of the plugin
>splitting-out, that would be awesome. On the priority list though, I think
>it's pretty low. Right now you have to set up the project f
If someone wants to lead the charge on this angle of the plugin
splitting-out, that would be awesome. On the priority list though, I think
it's pretty low. Right now you have to set up the project file, add the
JS, and then run the tests. This model will still work when plugins are
separated out.
I don't want to jump forward too far, but would it make sense to breakup
mobile-spec in a similar way so that the tests for a plugin are actually
located in the plugin's repo? Then the test and the function under test would
be synchronized. And it could potentially open the way for third-parties
