Found a couple of typos in the site/docs. It would be really easy to fix with a pull request, and would be nice to have people contributing to the docs as well.

It's written in a hurry and needs a cleanup before we can feel good about fixing the various timing issues etc we're currently having.

It would be nice to be able to comment out nested test cases just like single tests.

buster.testCase("...", {
  "//should defer test": function () {
  },

  "//nested testcase": {
    "should be deferred too": function () {
    }
});

When running lots of tests, the dots reporter will eventually hit the right edge of your terminal. We should make it wrap on a new line, simultaneously reflowing the rest of the table.

When I run buster static for a requirejs application it fails with this exception:

Uncaught Error: Module name 'fs' has not been loaded yet for context: _
http://requirejs.org/docs/errors.html#notloaded
req.onErrorrequire-jquery.js:1524
context.requirerequire-jquery.js:1241
requirejsrequire-jquery.js:1470
addCSSbuster-static-html-reporter.js:184
htmlReporter.setRootbuster-static-html-reporter.js:39
htmlReporter.createbuster-static-html-reporter.js:14
(anonymous function)buster-static-browser-run.js:3
(anonymous function)buster-static-browser-run.js:7

I believe (without doing too much analysis) that in order to know wether or not the code runs in a node-environment a test is made wether the require function is defined. Requirejs defines a require-function so the test passes and the browser code believes that it executes in a node environment.

If this is correct, perhaps it would be good to have a way to test for a node environment on the buster-object. That way the test can be rather involved and changed when problems like this is discovered.

Timeouts are currently given to the test runner. It should be possible to set this.timeout in a test, setup or whatever for more fine-grained control.

https://github.com/eriwen/javascript-stacktrace

The getResourceViaHttp method causes duplication and a resource set really shouldn't know anything about HTTP.

When testing with RequireJS, you typically use relative requires:

require(["lib/my-thing"], function () {
    ....
});

The URL of the page the tests are in is /sessions/[uuid]/resources/, causing RequireJS to attempt to load /sessions/[uuid]/resources/lib/my-thing.js. Buster however provides the file as /sessions/[uuid]/resources/absolute/path/to/lib/my-thing.js.

Possible solutions:

1. Use the relative paths when running tests, instead of absolute paths.
2. Provide a context path, so one can do something like require([buster.contextPath + "/lib/my-thing"]).

The latter is an option - typically when testing RequireJS apps you don't put "sources" or "deps" in your config file, just "tests", since you require the relevant implementation code in the tests themselves, nodejs style.

Just thought of a complimentary approach to the one described in #15.

If there was a requirejs extension for buster that would do this:

1. create two functions in global scope
   • define(deps, body)
   • require(deps, body)

Then buster has full control over which modules are loaded and could if necessary rewrite paths etc. Internally it would probably be wise to delegate to requirejs somehow since requirejs has a lot of plugins and stuff that would be a pain to emulate properly (I guess...). The merits of this approach I think is:

1. buster would know when everything is loaded since it is in the drivers seat
2. buster could allow the testwriter to declare something different than the real thing to be returned for a named module

buster.moduleStubs({"server/queue", function(element) {...emulate queue...}});

Totally insane?

This feature relies on the events that are emitted from the configuration loader. Currently it emits the events before resolving the glob patterns, so "file" is matched against "src/*/.js" rather than actual file names.

My decision to remove some assertions and the ability to provide custom assertions did not prove popular. Revert pls.

It fails to compile, and in general we'd like to avoid compiled modules for simple setup.

Don't make one XHR for each and every event sent by the in-browser test runner.

I ran the setup.js and all the dependencies were brought done and linked successfully. But when I tried to run a test again I got this error.

Error: Cannot find module 'buster-glob'
    at Function._resolveFilename (module.js:334:11)
    at Function._load (module.js:279:25)
    at Module.require (module.js:357:17)
    at require (module.js:368:17)
    at Object.<anonymous> (/javascript/buster/buster-configuration/lib/resource-set-builder.js:3:12)
    at Module._compile (module.js:432:26)
    at Object..js (module.js:450:10)
    at Module.load (module.js:351:31)
    at Function._load (module.js:310:12)
    at Module.require (module.js:357:17)

Just starting out with buster, so I quite possibly may have done something wrong, but when I type in
buster autotest I get the following stack trace

Error: Cannot find module 'watch-tree'
at Function._resolveFilename (module.js:334:11)
at Function._load (module.js:279:25)
at Module.require (module.js:357:17)
at require (module.js:368:17)
at Object. (/usr/local/lib/node_modules/buster/bin/buster-autotest:2:17)
at Module._compile (module.js:432:26)
at Object..js (module.js:450:10)
at Module.load (module.js:351:31)
at Function._load (module.js:310:12)
at Array.0 (module.js:470:10)

I can get round this by installing watch-tree

sudo npm install watch-tree -g

But then I get a different error...

buster autotest

Watching /xxx/src/test

/usr/local/lib/node_modules/watch-tree/lib/watchers/stat.js:148
throw err;
^
Error: ENOTDIR, not a directory '/xxx/src/test/.DS_Store'

I am on OSX and the .DS_Store file is created automatically (meta data used by the finder app)

Uncaught exception: Uncaught exception: ReferenceError: Undefined variable: AsyncTestCase

Not really a true problem, as sinon and good code layout removes the need for it. Still, raising this as an issue for the sake of consistency and at the end of the day - it may just prove useful for people trying to migrate...

http://code.google.com/p/js-test-driver/wiki/AsyncTestCase

TestCase("assertEquals incompatibility", {

    "test objects should be equal": function()
    {
        assertEquals({"test":123}, {"test":123});
    }

});

In JsTestDriver:
Opera 11.60 Mac OS [PASSED] assertEquals incompatibility.test objects should be equal

In buster:

    AssertError: expected {"test":123} but was {"test":123}

This particular one would let me pass extra ~50 of ~120 tests in one project just like that on both tools.

JsTestDriver uses AssertError, in contrast to AssertionError, used by Buster. Fix.

Buster currently can't facilitate these types of tests:

require(["my/file"], function () {
    buster.testCase("blah", {
        // ....
    });
});

The difficulty lies in knowing when all the buster.testCase functions have called. body.onload is not enough, due to the async require. We need to know when the test run has "finished" so we can end the session in buster-capture-server and exit the "buster test" process in the terminal, so we can't just wait 10 seconds and hope all the tests have loaded by then..

We need some sort of counter to let buster know before body.onload how many test cases that it expects to load. Suggestion:

buster.asyncTestCase(function (testCase) {
    require(["my/file"], function () {
        testCase("My test case", {
            // ....
        });
    });
});

With this model, buster knows at body.onload that there is one async test case that will be loaded in the future. It can wait for the passed "testCase" (which is just a wrapped buster.testCase) function to be called and know that if it isn't called it can timeout, and so on.

If you like using a step debugger, you'll face problems with the server because it namespaces paths with the session id for every run. That means the browser never sees the "file" you put the break-point in, causing step debuggers to not do anything useful at all.

Could we perhaps serve files over a /sessions/current/ URL or something like that to avoid this problem?

Originally reported by Judofyr a couple of minutes prior to switching to this issue tracker.

https://busterjs.org/old_issues/87

It's very annoying to get this error without knowing which file or line number:

Uncaught exception: Uncaught SyntaxError: Unexpected token {

(Originally reported here: https://busterjs.org/old_issues/87)

Also, for xUnit test cases, something like setUp/tearDown and contextSetUp/contextTearDown.

Node v0.6.2.

See https://gist.github.com/1453543 for example code.

That will create this line of code in the browser:

<script src="js" type="text/javascript"></script>

Also, if I rename my test-directory to "t", I'll get this:

<script src="pp.js" type="text/javascript"></script>

So clearly it removes the first n characters of the libraries, where n is the length of the name of the test directory.

That's bad.

http://busterjs.org/docs/hybrid-testing/

Example:

{ path: "/bundle.js", combine: ["*.js"] }

The following configuration:

{ load: ["/my/script.js"], resources: [{ path: "/my/script.js", content: "// Boo" }] }

currently fails, because buster-configuration always hits the file system when prepping load. It should consult resources before checking the file system.

TestCase("counting", {

    "test should pass": function()
    {
        assertTrue(true);
    },

    "test should fail": function()
    {
        assertTrue(false);
    }

})

Buster reports: 1 test case, 2 tests, 0 assertions, 0 failures, 1 error, 0 timeouts

Not sure if 0 failures is related to #31 but the 0 assertions is definitely incorrect.

Provided this config:

config["web-module"] = {
autoRun:false,
environment: "browser",
rootPath: "../web/resources/public/",
tests: [
"test/module//*-test.js"
],
resources: ["js//*.js"]
// sources: ["js/require-jquery.js"]
}

(buster.js is located in test/buster.js and the other paths can be figured out from the config above).

When I try to capture the browser I get this exception:

buster-server running on http://localhost:1111

module.js:334
throw new Error("Cannot find module '" + request + "'");
^
Error: Cannot find module './../../vendor/json/json2'
at Function._resolveFilename (module.js:334:11)
at Function.resolve (module.js:372:19)
at Object.createResourceSet (/Users/jocke/opt/buster/buster-capture-server/lib/capture/captured-client.js:106:17)
at Object.create (/Users/jocke/opt/buster/buster-capture-server/lib/capture/captured-client.js:23:27)
at Object.captureClient (/Users/jocke/opt/buster/buster-capture-server/lib/capture/capture-middleware.js:87:33)
at Object.respond (/Users/jocke/opt/buster/buster-capture-server/lib/capture/capture-middleware.js:22:27)
at Object.respond (/Users/jocke/opt/buster/buster-capture-server/lib/buster-capture-server.js:20:26)
at Server. (/Users/jocke/opt/buster/buster-capture-server/lib/buster-capture-server.js:90:24)
at Server.emit (events.js:70:17)
at HTTPParser.onIncoming (http.js:1478:12)
johlrogges ~/dev/agical/zeroadmin on feature/persist-user-settings(280986b) exited 1
56 zeroadmin:feature/persist-user-settings!? % buster server 14:06:18
buster-server running on http://localhost:1111

module.js:334
throw new Error("Cannot find module '" + request + "'");
^
Error: Cannot find module './../../vendor/json/json2'
at Function._resolveFilename (module.js:334:11)
at Function.resolve (module.js:372:19)
at Object.createResourceSet (/Users/jocke/opt/buster/buster-capture-server/lib/capture/captured-client.js:106:17)
at Object.create (/Users/jocke/opt/buster/buster-capture-server/lib/capture/captured-client.js:23:27)
at Object.captureClient (/Users/jocke/opt/buster/buster-capture-server/lib/capture/capture-middleware.js:87:33)
at Object.respond (/Users/jocke/opt/buster/buster-capture-server/lib/capture/capture-middleware.js:22:27)
at Object.respond (/Users/jocke/opt/buster/buster-capture-server/lib/buster-capture-server.js:20:26)
at Server. (/Users/jocke/opt/buster/buster-capture-server/lib/buster-capture-server.js:90:24)
at Server.emit (events.js:70:17)
at HTTPParser.onIncoming (http.js:1478:12)

I also tried: node install buster in the directory from which I run buster server. Don't know if this would change anything but the results are the same.

When I check ls /Users/jocke/opt/buster/buster-capture-server/vendor/json the directory is empty.

I'll dig some more to see if I can figure out why that is...

Currently resource sets attached to a resource set manager are practically immutable. Any operations on the resource set such as addResource done afterwards won't affect the resource set manager. This causes a few problems, particularly implementations that use buster-resources, since all modules needs to be aware of the resource set manager and create resources via it.

The docs mention a "buster static" command for browser testing. But it appears that it doesn't work. It just says that it's not a recognized command. And I noticed there's no buster-static file in the bin path.

Hello, World!

Currently buster-static has it's own completely separate and half assed wiring. Instead of adding support to autoRun in it, buster-static and buster-test-cli should share some of the wiring so the same code is used to support autoRun: false and buster.run().

We can probably utilize https://github.com/substack/node-burrito for the actual wrapping, for knowing what was called.

This is a feature request, I guess... I also think that there may just be a better way, without using "magic comments" to set up HTML and tear it down after the test finishes. Whether this is accepted as an issue for buster-jstestdriver that should be ported as documented in http://code.google.com/p/js-test-driver/wiki/HtmlDoc or becomes a whole new thing - I'd be glad to help fixing this issue as my New Year's resolution, as long as there's someone whose resolution is to help me with npm learning curve...

TestCase("Doc block", {

    "test should find element from DOC": function()
    {
        /*:DOC+= <div id="test">test</div> */

        assertNotNull(document.getElementById('test'));
    }

});

assert.exception(function () {}), i.e., with a function that doesn't throw causes an error where Sinon(!) tries to to toString an undefined value. This is most likely a bug in the wiring stuff, as the assertion passes all its tests in isolation (i.e. the buster-assertions package).

buster --help should give you a list of possible actions and some general pointers as to how to get started.

the primary feature that i dont see available yet that we use from jstestdriver is the ability to run the tests using the same process used to test drive server-side code within the ide. running the server within the ide is not as important as being able to create a run configuration to kick off the tests in the flow of tdd

It's unstable..

No work will be done for buster-server in older IEs than IE6 at this time, as buster-static is a viable alternative.

If you have a test with an assertion error in the tear down function and an error of some sort in the test, the runner only reports the teardown error, which is misleading:

var buster = require("buster");
buster.spec.expose();

describe("Thing", function () {
    before(function () {
        array = [1,2,3]
    });

    after(function () {
        expect(array.length).toEqual(4);
    });

    it("...", function () {
        asd.sdf.sd.f.sdf = 2;
        array.push(4)
    })
});

Buster is beta so this is to be expected, but it's a bit difficult to contribute atm. The project is really modular which is a good thing, but between all the submodules, hosted repos, the setup.js, and requiring a gitorious account/public key it's a bit daunting. Most people are used to simply forking a github project and then sending pull requests.

I think the answer is probably just better documentation, and maybe consolidating the repository hosting to either just github or just gitorious but not both. Also - are setup.js and update.js really necessary? Whatever we can do to lower the barrier to entry would be great. That's my feedback as a JS dev who wants to contribute.

Make sure all assertions (even the "new" ones) are documented, and that they all include the optional message argument.