search

jspm / demo-es6

Demonstration of the jspm loader and CLI workflow for ES6 modules
40 stars 10 forks source link

Mocha testing example #8

Open stuartc opened 9 years ago

stuartc commented 9 years ago

Hey @guybedford!

Do you have any advice or example running mocha?

Is there a way to run mocha (which was installed with jspm)? Or should I be using the bin that comes with the npm installed copy?

guybedford commented 9 years ago

Oh hey! Do you mean running mocha in jspm? On the server/browser or in Node? I've created an issue at https://github.com/jspm/registry/issues/158, let me know if that's what you're after here.

capaj commented 9 years ago

@stuartc I've incidentally ran mocha in the browser to test and Angular app which is powered by JSPM/systemJS. Will make a post tomorrow about it. @guybedford I will also try to come up with a solution how to override the latest version of mocha, but it is tough one to crack. So far I am using classic script include to load it into the browser.

guybedford commented 9 years ago

@capaj saw your jspm post, looked really great! Do let me know how things go with getting mocha configured or if you need help with this at all.

raphaelokon commented 9 years ago

@guybedford Can you point me to @capaj's post?

capaj commented 9 years ago

@nordisk the post doesn't actually have any code, let me prepare a showcase for you.

raphaelokon commented 9 years ago

@capaj Cheers for that!

capaj commented 9 years ago

@nordisk take a look here on a project I have started this weekend: https://github.com/capaj/postuj-hovna/tree/map-selected-entity/www/.test

it is just a special test folder inside an http served directory(usually public). In there, we have a special index.html which we can load and the tests will fire. Important bit is: https://github.com/capaj/postuj-hovna/blob/1c1889cd2ec2be1d31a52f17edf18eabaacc6604/www/.test/index.html#L14-L16 and obviously importing the master spec file on the next line, which should require/import all individual spec files into the browser. Otherwise, the index is identical to regular index.html

When the directory is served with browsersync, you will get the rerun on any code change for free. No need for complicated config files. So to run the tests in that particular project, I just fire up browsersync and then navigate to http://localhost:3000/.test/index.html This approach will work for any app-be it Aurelia, Angular, React or whatever. Bonus is that debugging these tests is as straightforward as debugging the real app.

NOTE about these specs: I have there just two empty specs because I will need to learn ho to instantiate aurelia modules for tests, I cannot test it without it.

vincemtnz commented 9 years ago

@capaj I think one of the main drawbacks with your approach is that you have to hardcode the path to mocha (and chai, etc), so your hardcoded links (which are versioned) are prone to break if you update mocha.

The other obvious offender is having to manually maintain a list of spec files that will be tested: we've all been spoilt by test runners and globs, so not being able to simply say {files: ['client/**/*.spec.js']} will feel like a step back. But if the scope of @stuartc's question was simply how to get files loaded via System.import() to run with mocha, then yeah, that works. It does feel like we need some tooling around this to make our lives easier!

I'm wondering how feasible it is to use gulp watch to run tests (like we're already used to), adding a task that would take a gulp.src('app/**/*.spec.js') and convert it to a list of imports / requires that can be loaded by System.import(). Feels quite fragile though.