You can install it using npm install jester-tester@next. I've been working on it for a while now and it has a bunch of needed improvements such as being able to configure webpack and eslint directly. However I'm currently beta testing it and I have yet to add a migration script. Eslint is doing a lot of breaking changes at the moment while they're ramping up for their 1.0 release so I won't make the @next version the default until after the 1.0 eslint release. I also might replace karma with testem before that.

But me and my team are using the @next version full time, so it probably won't delete your entire file system. I encourage new jester users to start with the @next version. Just be aware that you might have a non-automatic upgrades (usually changing some settings, renaming some properties) for new releases.

The goal of Jester is to give you a bootstrap for integrating these tools so you can worry about your app code and not about the tooling. It can run in batch mode or it can watch your source directories for changes and rerun tests immediately when you update your sources.

Installation

Install jester from npm and save it into the development dependencies. Under windows you'll have to run this as administrator (required by jsdoc for creating symlinks):
npm install --save-dev jester-tester

Creating a project

Initialize your project. This will create the required folders and
a jester.json configuration file with default values for your project:

./jester.json # configuration for jester
./jsdoc.conf # configuration for jsdoc, see: http://usejsdoc.org/about-configuring-jsdoc.html
./readme.md # the readme is in markdown and will be included in the jsdoc output

Writing features with jester

Jester assumes that you build your application from features. Each feature will
be a separate js file that you can load from an html file in the browser by
using <script src='myscriptsdir/myfeature.js'>.

Jester packages your features with their dependencies with the help of webpack.
It accomplishes this by searching for a file named feature.js in a subfolder
of src/features/.

To show how this works we'll create a javascript app which just logs "hello
world" to the console.

The feature is contained in src/features/greeting/feature.js:

/*globals console*/

// dependencies are imported using commonJS

var hello =require("../../lib/hello");

console.log(hello());

The hello function is found in src/lib/hello.js:

functionhello(){

return"hello world!";

}

module.exports= hello;

Generating the results file

Executing ./node_modules/.bin/jester-batch.js results in two files.
greeting.min.js and greeting.min.js.map. The .js file contains the full
javascript code (both feature.js and hello.js). The map is a source map which
maps the source code in the compiled .js file to the original files and lines
for use in the browser debuggers that support this (chrome and firefox atm).

Note!: Source maps are not always interpreted and not all browsers support
the same features.

You have to enable them manually in chrome (FF has them enabled by default)

You won't see the stack traces source mapped in jester's shell output

You should see the stack trace source mapped when opening the development
console in chrome. Firefox doesn't source map stack traces and I haven't
found a way to enable it.

warnings

You might notice some warnings in the output. This is eslint telling you that
using console in production code is frowned upon. Some other eslint tests are
configured as errors and jester will flat out refuse to generate the
greeting.min.js file if you forget to put a var in front of hello. You can
configure eslint in the file jester.js.

You can also create your own project specific custom eslint rules that analyse
the javascript syntax tree. If you place them in eslint-rules eslint will
automatically load them.

If you think jester-batch is too slow

Jester-batch takes a while to launch and this gets tiresome. So you can also run
jester-watch (node_modules/.bin/jester-watch.js) which will keep running and
therefore generate the result files much more quickly.

Writing a test

Each javascript source file can (and should) have a corresponding file with the
unittests for that piece of code. This file must have the same name of the
tested code, with a .test.js suffix.

So let's start with hello world by creating the test file
./src/lib/hello.test.js:

//Tests are normal js modules, so they load the module under test using commonJS

var hello =require("./hello");

// jasmine is implicitly available in .test.js files

describe("Greetings",function(){

it("returns `hello tested world`",function(){

expect(hello()).toBe("hello tested world!");

});

});

This test asserts that the function hello will return the string hello tested world.
The test will run upon saving it if jester-watch is running, or else when you
execute jester-batch.

Jester will now run your tests in the browsers as specified in jester.js. Of
course the test will fail because the result of hello is different. Fix the file
hello.js file src/lib/hello.js and try running jester-batch again:

functionhello(){

return"hello tested world!";

}

module.exports= hello;

Dependency injection

Jester makes it easy to replace a 'require'd module in the source file with a
test-stub.

Let's say we have a file called src/lib/db.js

var retrieveHello =require("db/retrieveHello")

module.exports=functiondb(){

returnretrieveHello("pgsql://mypgserver")

}

and that hello.js uses that:

var db =require("./db");

functionhello(){

returndb();

}

module.exports= hello;

Then you're tests will fail because (a) you're missing the javascript module
that implements retrieveHello and even if you would npm install it, your test
would be dependant on pgsql://mypgserver.

Instead your test should inject a shim for db.js

/**globals console*/

functiondbShim(){

return"Hello tested and injected world!";

}

var helloMaker =require("jester-tester/src/injectable!./hello");

var hello =helloMaker({"./db": dbShim})

describe("Greetings",function(){

it("returns `hello world`",function(){

expect(hello()).toBe("Hello tested and injected world!");

});

});

I encourage you to log the helloMaker function to the console so you can see
what happens under the hood. It's not really magical.

Generating documentation from source

Documentation will be generated from appropriately annotated sources by jsdoc and includes the syntax highlighted source code. See usejsdoc for how to annotate your code, especially relevant is Document CommonJS Modules.

There are many ways to export and document code. The recommended way to export functions is:

This enables jsdoc to recognize that clone is a (static) function, the clone symbol will show up in stack traces and is fully supported by IE8.

The api documentation will be written to a directory specified by the apiDocPath setting in jester.json, which defaults to ./doc/api/. You can set the configuration option readme to point to a file that is a markdown formatted readme which will be included in the generated documentation on the homepage.

The api documentation will be generated when you run jester-batch or jester-doc. The latter is a bit faster because it only runs jsdoc. The documentation is not automatically updated when running jester-watch.

An additional benefit of annotating your code with jsdoc style comments is that there are a number of tools such as ide's and compilers which can take advantages of the additional information contained in those comments.