- Use Karma to run the tests.
- Support specifying LOOT UI index page as CLI argument, and
treat localhost URLs like http://loot URLs, so that Karma
can get LOOT to launch the test page.
- Fix the JS query tests when run in LOOT, as window.cefQuery
can't be stubbed in CEF.
Chai is more popular and so has more examples for getting in-browser
tests run from the command line (I haven't found any for should.js)
using third-party modules, which will be more helpful than sticking with
should.js.
The only downside is that chai doesn't have neat Promise assertions, and
the chai-as-promised plugin that adds them doesn't support browsers
without something like Browserify involved.
The Vulcanize script can now build the UI, the element test files, or
both, defaulting to the latter.
The `mkdirp` package is used as it's the simplest way of getting
recursive `mkdir`, ie. `mkdir -p`, to work.
Using Sauce Labs and Grunt. Also install runtime dependencies
using Bower to get the Jed package that's used in testing, and
save the Bower version resolutions for Travis so that step can be
automated.
Start with making plugin.js into a module, and re-implementing Plugin
using the class-based ES6 syntax, as it's a lot cleaner. Dispatch
events from setters instead of using Object.observe when changing
values that prompt external changes.
Vulcanize's whitespace stripper doesn't like the ES6 syntax though, so
disable that.
Also start implementing some tests using Mocha and should.js.
Finish refactoring JS Plugin code
To help enforce a consistent JS code style and improve code quality by
catching various syntax gotchas.
I'm editing in Atom with the linter-eslint package installed, and it
gives me inline warnings and errors, very handy. I'm not going to run
ESLint on Travis (yet) though, as it spits out far too many errors for
it to be useful.
Oliver Hamlet