asynchronous testing about bunit.js

[bebraw]

Hi,

I never really did test bunit.js with asynchronous tests. If you can provide some minimal test case illustrating the issue, I don't mind fixing this. Thanks! :)

[palodequeso]

I use sinon.js to fake a backend for js unit tests
Here's a simple example of a bunit test suite:

define(function(require) {
    var bunit = require("external/bunit/bunit");
    var assert = require("external/bunit/assert");

    var $ = require("jquery");

    bunit("Request manager", {
        tearDown: function() {
            $(".btn").click();
        },
        sample_async_test: function(r) {
            var server = sinon.sandbox.useFakeServer();
            server.respondWith("GET", "/test/1", [
                200, { "Content-Type": "application/json" },
                '{"response": "some_response"}'
            ]);

            $.ajax({
                type: "GET",
                url: "/test/1",
                success: function(data) {
                    assert(data.response).equals("some_response");
                }
            });
            server.respond();
        }
    });
});

PS: I love this unit testing stuff, I might have some pull requests for you in the somewhat near future too. I added the ability to turn off the try catch so I can actually see some form of traceback when dealing with errors in the actual code that the tests found.

[bebraw]

QUnit seems to solve this by providing start and stop functions. In addition there's some automation (implicit stop if a test is named certain way). I think in our case, we could try something similar unless you have some idea. Just to make sure we're on the same page here, I think it would look like this:

define(function(require) {
    var bunit = require("external/bunit/bunit");
    var assert = require("external/bunit/assert");

    var $ = require("jquery");

    bunit("Request manager", {
        tearDown: function() {
            $(".btn").click();
        },
        asyncTest: function(r) {
            var server = sinon.sandbox.useFakeServer();
            server.respondWith("GET", "/test/1", [
                200, { "Content-Type": "application/json" },
                '{"response": "some_response"}'
            ]);

            // call stop(); now if you want, since we named our test using async prefix,
            // that won't be needed
            $.ajax({
                type: "GET",
                url: "/test/1",
                success: function(data) {
                    assert(data.response).equals("some_response");
                    start();
                }
            });
            server.respond();
        }
    });
});

Would this work for you?

PS: I love this unit testing stuff, I might have some pull requests for you in the somewhat near future too. I added the ability to turn off the try catch so I can actually see some form of traceback when dealing with errors in the actual code that the tests found.

Great. :)

[palodequeso]

I've migrated away from qunit so my code is already setup this way so that would be perfect! Thanks!

[bebraw]

I ended up simplifying design of bunit.js. Now setUp parameters are passed inside an Object. In case of async tests (prefixed with "async") there is another parameter, "done" callback. Simply call that once finished with the async ops.

I added a TODO for you to the source should you feel like developing the solution further. Now it gets stuck if the async op won't finished. It might be nice to have some kind of a configurable timer in place to avoid this situation.

[palodequeso]

Thanks for your help, this should work like a charm. PS: If my test has no setup, will I still need to make an async test method take two parameters (setup_object, done) or will it receive done as the first parameter?

[bebraw]

PS: If my test has no setup, will I still need to make an async test method take two parameters (setup_object, done) or will it receive done as the first parameter?

In this case the first parameter will be undefined. So without setup you could have tests like asyncTest(o, done) and then invoke done as usual. This is just to keep it consistent. It's easier to add setup later on this way should you need it. No need to tweak the code a lot.

[bebraw]

@palodequeso Forgot to ask... Would you find suite.js useful in your work? I designed it mainly to test my Node libs but with very little effort I could port it to browser usage.

Conceptually it is very light. I know the syntax may look a bit weird at first but once you get a hang of the basic idea it's actually quite powerful. And you can use generative testing with it. :)

[palodequeso]

That would definitely be useful. We have lots of functions which we sometimes bombard with lots of little tests. We use node for python testing and we do something similar with yields. Keep up the good work!

[palodequeso]

Can I also recommend that at some point you add a full async test to your tests. I see you have a few tests in there that just call done. Why not write a full ajax async test at some point?

[bebraw]

@palodequeso I started an issue for this. I'm particularly interested in the use cases you have in mind.

As I hinted suite.js has been designed in a very specific way. This leads to some restrictions but makes it highly useful for certain purposes (testing functions).

[palodequeso]

I was more referring to adding more comprehensive async tests to bunit for now as well.

[bebraw]

@palodequeso Gotcha. Could you post separate issues for your ideas?