Repository navigation
.tests field #49
Description
since apps are already split up into components, why not tests? i'm not 100% sure how this would work yet, but i want each component to be able to have its own tests:
{
"name": "router",
"dependencies": {}
"development": {
"dependencies": {}
},
"tests": [
"tests/*.js"
]
}then a test runner could go through each component (in resolution order) and run each file after building the component in development mode. thus, no more test/ folder!
we could add more structure to this like requiring the tests to be of the form:
test.js
test/*.js
tests/*.js
so it could be run easier outside of component (i.e. mocha cli). we can have a shortcut "tests": true for this.
Activity
dominicbarnes commentedon Jan 22, 2014
+1 if we can also give test scripts the same CommonJS benefits.
johntron commentedon Jan 22, 2014
I've already been using .tests with my test suites, so a big +1 here!
jonathanong commentedon Jan 26, 2014
i'm thinking that this would expose a
require('test')or something that once required will execute the tests. socomponent testwould just run something like:and everything will be executed. the builder will have to bundle the tests and dev deps correctly.
one thing we're going to run into is not being able to do
require('assert')from outside the built as there won't be any more aliases. this would solve this issue as tests are included within the build, so it'll be able to resolve all these dependencies.tj commentedon Jan 27, 2014
SGTM
tj commentedon Jan 27, 2014
either that or maybe since we're doing the nested env thing with
.developmentmaybe just having them in.development.scriptswould make sense?jonathanong commentedon Jan 27, 2014
i was thinking that it would basically be
.development.scriptsbut with an additional entry point (instead ofindex.js). otherwise, it's not totally clear which.development.scriptsare the tests to the test runner. not totally sure yet. we could also be more strict and require tests to be in atest/folder or something - that would work in.development.scripts, though i'd rather be explicit withtests = [stuff]jonathanong commentedon Mar 29, 2014
i'm now thinking that
component build testswill create a standalone build with relevant js, css, and files with atest/index.htmlentry point. then we can publish this entire folder togh-pages/testwith a--branch gh-pagesoption, then going tocomponent.github.io/emitter/testwill run all the tests in the browser.this might be a good way to do cross-browser testing, especially on an arbitrary system and browser. "can you go to this address and tell me what happens?" less opinionated than integrated saucelabs support and such.
i'm also thinking of integrating mocha since it's what 99% of components use.
what do you guys think?
jonathanong commentedon Mar 29, 2014
also, doing saucelabs or whatever testing would be easier if we build everything into a small package.
ianstormtaylor commentedon Mar 31, 2014
i like the idea of wrapping it up into a standalone. i think it should be it's own command though instead of being attached to build. the command could run
build --devinternally i think, but lots of the other stuff is kinda opinionated for coregh-pagesmight be problematic because people might want to use that for other things, so i wudnt want component testing to require clobbering pagesjonathanong commentedon Mar 31, 2014
yeah i dunno. it could build automatically with
build --devbut have arequire('tests')entry point or something.component build testsjust sounds the most semantic to me. maybecomponent build --testsi was thinking
--branch gh-pages --out test, which creates atest/index.htmlfile, so people can designate a specific page just for tests. i'm not sure where to put these files in the current workflow. shouldn't clobber anything since you'll have to specify everything manually.