Update capture-server and use new implementation, “ramp”. This should
vastly improve the stability of the server as well as print proper
error messages (and use correct exit codes) when the server is not
running or has no connected slaves.

This release also introduces a few of the 1.0-ready modules slated for
0.7, but few user-facing updates.

This is a list of breaking changes in this release. Since we haven’t reached
1.0 stable yet, we’re taking the freedom to change APIs without making them
backwards compatible in the hope of making them better. There are a few more
breaking changes planned for the next (last) beta, see Roadmap.

In an effort to improve navigation in the many Buster.JS modules, we have
started renaming some of them, as discussed on the mailing list.
These naming changes will only affect you if you are depending on either of
these modules in your own projects.

buster-resources is now ramp-resources (the capture server will
eventually become “ramp”)

--log-all is gone. In Beta 3, Buster.JS would silence log messages for
passing tests and this option would show all messages. In Beta 4, Buster.JS
shows all messages by default, and silences those from passing tests with
--quiet-log.

Hooks fire in a given order. The beforeRun no longer comes with
any arguments. To get hold of the analyzer and configuration objects
that used to be passed to it, implement analyze(analyzer) and
configure(configuration) (called in that order) in addition.

The main theme of this release is a rewritten and vastly more stable capture
server. Significant work has also been put into making it easy to use the
server and the related command-line interfaces with any test framework (e.g.
it should now be possible to use these tools to create a qunit-test
binary that runs QUnit tests over the server).

Implementation and API-wise, the buster-test-cli module is now completely
test framework-agnostic. The framework sources are injected as an extension
in the “binary” script that uses. In other words, the Buster.JS test
framework is now just a regular extension to the Buster.JS CLI tools.
For an example, see buster-test.

All modules now have a working npmtest. All modules are also configured
with continuous integration on Travis CI, but will need further love to make
the setups work nicely on Travis (basically we have some ugly circular
dependencies that needs to be done away with).

The autotest module has seen significant improvements through Magnar Sveen’s
work on fs-watch-tree. The
autotest command-line interface itself also received some usability upgrades.
Autotest should now work flawlessly on Linux and OSX (Windows unconfirmed at
this point).

Re-run all tests by tapping Ctrl-C. Hit Ctrl-C twice to stop. Currently only
works for buster-autotest, not busterautotest.

Individual resources have cacheable: true|false. This means extensions can
control cacheability (i.e. repeatability for warnings etc) on a very
fine-grained level.

Resource Etag changes when adding processors. Avoids caching issues: If an
extension is added in a configuration file, the cache manifest would not
update. With this change, any extension that adds processors will cause the
cache manifest for affected resources to update, avoiding any stale cache
lookups.

Propagate resource content processor exceptions.

Root resources can specify where to insert scripts by adding {{scripts}}
to the template contents.

The buster.js configuration file you put in your projects has a strict focus
on project-related settings. This means that it intentionally does not support
personal preferences like --colordim. This is where ~/.buster.js (or
~/.buster.d/index.js if you prefer) enters. Currently the following
settings can be provided:

test.releaseConsole. If true, never capture the console.

test.quietLog. If true, never print log messages for passing tests.

test.color. One of “dim”, “bright” (default) or “none”.

To specify preferences, ~/.buster.js (or (~/.buster.d/index.js) should
look like this:

Windows support work is ongoing. In this version, Node tests with the
buster-test command-line interface is working, while the server and browser
automation part is still not quite there. If you need Windows support, please
consider chipping in.

This is a list of breaking changes in this release. Since we haven’t reached
1.0 stable yet, we’re taking the freedom to change APIs without making them
backwards compatible in the hope of making them better.

This is a simple change of words. testHelpers resonates better with most
uses of the property than testLibs. It behaves like before, meaning that
e.g. when you run single tests with bustertest-ttest/my-test.js,
everything in testHelpers will still be loaded.

We’re renaming some expectations, basically to match the expectations in
Jasmine. We were already pretty close to their API, and being 1:1 means way
easier migration. Some expectations have also been added, you can find them
in the “Changes” section below.

toBeSameAs is now toBe. Example: expect(true).toBeTruthy()

toBeInDelta is now toBeNear, aliased to toBeCloseTo. Example:
expect(4.5).toBeCloseTo(4,0.5)

not() is now a property, not a function. Example:
expect(false).not.toBeTruthy()

Removed assertion

assert.typeOf was removed in favor of the more specific ones (e.g.
assert.isString)

buster.env.path is removed

Use buster.env.contextPath (was also available before beta 3) instead.
Note that buster.env.contextPath does not include a trailing slash.

buster-autotest works on all platforms where fs.watch is supported.
Autotest is also slightly clever, only running affected tests on each save
and running the entire suite when going from red to green.

Adding support for JsTestDriver style
/*:DOC+=<div>test</div>*/ with the new extension buster-html-doc.
This extension can be used both in vanilla buster tests and alongside
buster-jstestdriver. (#47)

The body of the testbed HTML in browser tests will now reset between each
test run. It will not be cleared out entirely, it will be set to what it was
initially. Note: this is not yet fixed in buster-static. (#74)

This is a brief (i.e. not exhaustive) overview of changes from Beta 1. Beta 2
introduces quite a few fundamental refactorings and rewrites, and is
significantly closer to a stable 1.0 release than its predecessor.

With Beta 2, we’ve entered a more rapid iterative development and release
cycle. In the four days since the initial release, three patch updates have
already been shipped. “Beta 2” refers to Buster.JS version 0.4.1 or newer,
until we decide to do a release candidate (or another major beta, if
necessary).

sources, tests, etc can no longer contain paths outside the root path.
The root path defaults to the path the configuration file is in. You can also
provide the rootPath property in the configuration file to base the project
outside the directory where the configuration file is located.

config["My tests"]={sources:["../src/**/*.js"],// Will not work!tests:["**/*-test.js"]};config["My tests"]={rootPath:"../",// Will work (or just move the config file up one folder)sources:["src/**/*.js"],tests:["tests/**/*-test.js"]};

Capture server: significant refactor.
“Clients” are now “slaves” and several URLs have changed.

Configuration file can now load extensions. A few
are already availble, and others, like buster-amd (#15) and coverage
is right around the corner.

buster-promise is now deprecated and will not receive further updates. We
recommend the wonderful when.js
instead–it’s what we use.

Buster now syntax checks files before attempting to run tests in browsers.
This ensures a stable environment with good feedback, regardless of target
browser.

The test runner was rewritten. It now supports per-test timeouts, the done
callback can be used to wrap functions (“we’re done when this function is
called”), asynchronous testCase and describe, and TeamCity reporter.

The test runner now has a system for including other measures in a test run,
issuing warnings, or even preventing tests from running at all. The first
external tool included in this system is buster-lint. Expect more
thorough documentation of this system as it evolves.

So far we have QUnit style static html page testing, JsTestDriver style browser
automation, and node testing. We have stubbing and mocking, setUp and tearDown,
asynchronous tests, hybrid browser/Node tests, and much more.

We don’t have a super stable 1.0 that you can connect to a zillion old
browsers to and have it run in a stable fashion in your CI environment. Getting
there requires field testing, and that’s where you come in.