This repository has been archived by the owner. It is now read-only.

Async test cases in browser, useful for AMD, RequireJS #15

Closed
augustl opened this Issue Dec 8, 2011 · 161 comments

Comments

Projects
None yet
@augustl
Member

augustl commented Dec 8, 2011

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.

@geddski

This comment has been minimized.

geddski commented Dec 8, 2011

What would that look like in the BDD style?

@magnars

This comment has been minimized.

Member

magnars commented Dec 8, 2011

I might be talking crazy here, but how about wrapping the require call? (ruby: alias_method_call, elisp: around advice) That way buster could keep a track of them without the extra syntax.

@cjohansen

This comment has been minimized.

Member

cjohansen commented Dec 8, 2011

I also thought of wrapping the require function. But that would have to be a RequireJS extension to reduce the boiler-plate, and we might need to consider other loaders as well. We can do that, but we need a generic underlying mechanism that the extensions can use. I think the current autoRun: false + buster.run() is not sufficient.

I really like @augustl's suggestion, but I'd like to do it without a "new thing". In particular I'd like to play on the "a function with a callback makes the thing async" concept we already have for tests:

buster.testCase("I am a testcase", function (run) {
    require(["something"], function (something) {
        run({
            "here's the test": function () {

            }
        });
    });
});

I'm not crazy about the nesting here, but we could provide extensions for popular AMD loaders that reduce the boilerplate. You can also improve the situation manually by using named functions and variables... This model also extends nicely to the BDD stuff:

describe("Something", function (run) {
    require(["something"], function (something) {
        run(function () {
            it("does things", function () {});
        });
    });
});

The cool thing about this suggestion is that we can easily support it directly in the test runner. This means it will be easy to reuse the logic should someone want to create a new frontend (i.e. something that's not testCase nor describe). It also means relatively few changes to support them - only in the runner and testCase + describe.

What say ye?

@magnars

This comment has been minimized.

Member

magnars commented Dec 8, 2011

Yes, that's nice. I like that it matches done. And with boilerplate-reducing extensions for popular script loaders, it's looking like an excellent solution.

@augustl

This comment has been minimized.

Member

augustl commented Dec 8, 2011

+1 to buster.testCase("foo", function (run) { run(rootContextHere )});!

@ghost ghost assigned cjohansen Dec 8, 2011

@cjohansen

This comment has been minimized.

Member

cjohansen commented Dec 8, 2011

Ok, I'll fix it. If anyone has any further insight, please share, I'll get this hammered out some time this week.

@geddski

This comment has been minimized.

geddski commented Dec 8, 2011

The ideal is that the only difference in your test is that it's wrapped in a require() block. So if your test normally looks like this:

describe("regular test", function () {
    it("should work", function () {
        expect...
    });
});

And you want to test an AMD module, now your test looks like this:

require(['lib/mymodule'], function (module) {
  describe("regular test", function () {
    it("should work", function () {
        expect...
    });
  });
});

That's works with Jasmine and QUnit, and it's nice. I don't have to do anything different to test an AMD module, just wrap it in a require() block and "import" the JS file(s) I want to test. That's the ideal in my mind.

Currently the following actually works (using an externally hosted AMD module because of Issue #16)

describe("AMD", function () {
    it("should work", function (done) {
        require(['http://raw.github.com/gist/3eb65c2883af6b6f2b8d/41b6fbfaf24b8106268dd3c770ad22a976afcf3e/mymodule'], function (module) {
            expect(module.name).toEqual("A Module");
            done();
        });
    });
});

but it's backwards having the require() inside the define() and the it(). It also means I'd have to require the file a ton of times: inside of every single it().

This would be the ideal if we can make it work:

require(['http://raw.github.com/gist/3eb65c2883af6b6f2b8d/41b6fbfaf24b8106268dd3c770ad22a976afcf3e/mymodule'], function (module) {
    describe("AMD", function () {
        it("should work", function () {
            expect(module.name).toEqual("A Module");
        });
    });
});
@cjohansen

This comment has been minimized.

Member

cjohansen commented Dec 8, 2011

Thanks for the input @GEDDesign. The "problem" with that solution when running through the server, is that Buster needs to have some idea what is supposed to happen and when. This is the background for my suggestion, in which Buster knows you have pending tests and wlil wait for them to complete.

We can build your suggested API as an AMD extension on top, but I don't want it hammered into Buster, cause we will need to wrap the require function to do that in a predictable way. By that I mean that you'll do (in your config file):

config["Browser tests"] = {
    environment: "browser",
    tests: ["**/*-test.js"],
    extensions: ["buster-amd"]
}
@geddski

This comment has been minimized.

geddski commented Dec 8, 2011

@cjohansen understood. Arriving at the ideal syntax with an extension sounds reasonable. And in the meantime your run() proposal looks pretty good, so long as you only need to do it once per file. So this:

describe("Something", function (run) {
    require(["something"], function (something) {
        run(function () {
            it("does things", function () {});
            it("does more things", function () {});
            describe('when hungry', function(){
                  it("does other things", function () {});
            });
        });
    });
});

and not this:

describe("Something", function (run) {
    require(["something"], function (something) {
        run(function () {
            it("does things", function () {});
        });
    });

    require(["something"], function (something) {
        run(function () {
            it("does more things", function () {});
        });
    });

     require(["something"], function (something) {
        run(function () {
            describe('when hungry', function(){
                  it("does other things", function () {});
            });
      });
});

You get the idea. A single run() would be totally fine.

@cjohansen

This comment has been minimized.

Member

cjohansen commented Dec 8, 2011

Right, only a single run. Anyway, the extension will be small, you can expect it no later than a few days after the runner understands this stuff :)

@geddski

This comment has been minimized.

geddski commented Dec 8, 2011

Awesome. I want to get up to speed on the buster code base so I can
contribute more meaningfully.

@augustl

This comment has been minimized.

Member

augustl commented Dec 8, 2011

Awesome. I want to get up to speed on the buster code base so I can contribute more meaningfully.

Be careful, buster-capture-server and buster-resources is in dire need of refactoring ;)

@geddski

This comment has been minimized.

geddski commented Dec 8, 2011

Yep I'm cool with it, so long as I can have a single require and a
single run per file as shown above.

@geddski

This comment has been minimized.

geddski commented Dec 8, 2011

Be careful, buster-capture-server and buster-resources is in dire need of refactoring

I ain't afraid :)

@geddski

This comment has been minimized.

geddski commented Dec 13, 2011

Running into any snags on this feature? It's the one thing preventing me from converting my projects over from Jasmine. Ok I'll stop buggin.

@cjohansen

This comment has been minimized.

Member

cjohansen commented Dec 13, 2011

Got tangled up in paths in the config file, in addition to being slightly overloaded at work. I'm hoping to get this ironed out this week. Sorry for the delay!

@johlrogge

This comment has been minimized.

johlrogge commented Dec 20, 2011

Now that the relative path issue is solved I have managed to get a simple test to work. I have also played a bit with embracing the jsrequire model for loading dependenceis and while it is a bit involved I'm pretty pleased with what I have accomplished.

Here is my config:

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

As can be seen from the config I start everything from the all-test.js file in test/module.
The all-test.js file looks like this:

require(["test/r-buster", "test/module/origin/storage-test"],
    function(buster) {
        // at this point we know all submodules has been loaded
        buster.run();
    });

Things to note:

  1. There are no tests in this file
  2. buster.run() is called in this module. This exploits the fact that js require guarantees that all child modules have been loaded before the parent module is initialized
  3. Consequently, the actual testcases are depended upon from the parent module. I have not verified this but it should work to also have child modules depend on other tests in their childmodules etc.
  4. buster is itself a dependency like any other requirejs dependency. This is not strictly necessary but is more "pure"

Now, lets look at how the buster module is defined

define([], function() {
    return buster;
});

We simply return the global buster object. This is a common trick in jsrequire but is not as good as having a module defining the buster object and returning it.

And now what you have all been waiting for. The testcase:

require(["test/r-buster", "js/origin/storage"],
    function(buster, storage) {
        buster.testCase("Some code module", {
        "will work": function () {
            assert(true);
        },
        "will work too": function () {
            refute(false);
        },
        "will fail": function() {
            assert.equals(storage, "this is a storage");
        }

        });

    });

Things to note:

  • buster is again a declared dependency. Even if buster would not be a global object require js would make sure it is the same buster object that is passed to all modules that require it.
  • the tested module 'js/origin/storage' is depended upon of course.

Now finally the subject under test:

define(["jquery"],
       function($) {
       console.log("got here");
       return "this is a storage";
       });

I'm pretty happy about this. I think requirejs in itself gets us a long way and buster will know for sure that all tests are defined before run. We don't have to add an asyncTestCase or similar to user requirejs.

Now, the bad news:

requirejs defines the method "require" globally. This is no issue in browsertesting but it does mess up static-testing (and I would assume node-testing).

At the moment I can live with that but it would be a good thing to create a plugin from AMD... so how does one create plugins? Where do I start? :)

@augustl

This comment has been minimized.

Member

augustl commented Dec 20, 2011

Why aren't you doing this?

buster.testCase("my test case", function (run) {
    require(["foo"], function () {
        run({
            // tests here ...
        });
    });
});
@johlrogge

This comment has been minimized.

johlrogge commented Dec 20, 2011

  1. Didn't know it was already implemented
  2. It is a bit backwards IMO, "my" way looks like any require JS-module and inside that module is what looks like any buster testcase. They don't overlap. The AMD-stuff is just wrapping the tests. I guess I share this opinion #15 (comment)
  3. After working with requirejs for a while "my" way feels natural to me. It is what AMD modules look like

I reserve the right to have the opposite opinion tomorrow or in 5 minutes :)

@augustl

This comment has been minimized.

Member

augustl commented Dec 20, 2011

Ah Chris only tweeted about it and hasn't updated this issue. I thought you were commenting because of the recent change that implemented this.

The idea is to patch require so that require("foo", function () {}) is basically the same as the example above. In other words just require, create buster.testCases in the callback, and nothing else is needed. No autoRun: false etc, just load the buster-requirejs plugin. This is just a small step two, now that async test cases are implemented this plugin should be easy to write. Baiscally it will do this:

(function () {
    var oldRequire = window.require;
    window.require = function (modules, cb) {
        buster.testCase.numTestCases++; // or something like that
        oldRequire(modules, cb);
    };
}());
@johlrogge

This comment has been minimized.

johlrogge commented Dec 20, 2011

That is pretty neat. Just realized that the requirejs-thingy automatically enables coffescript. Just install the cs-plugin and prepend cs! before the module name. Then the tests can be written like this:

define ['test/r-buster', 'js/origin/storage'],
       (buster, storage) -> 
        buster.testCase("some module", 
          {
            "will work": () -> assert(true),
            "will work too": () -> refute(false)
          })

freaky...

@johlrogge

This comment has been minimized.

johlrogge commented Dec 20, 2011

I tried the function(run) style and it did not work yet?

Uncaught exception: Uncaught Error: Tests should be an object

@cjohansen

This comment has been minimized.

Member

cjohansen commented Dec 20, 2011

I sort of eagerly tweeted about the function (run) approach because I have it working on my machine :) But it's not complete, so I haven't pushed it yet.

Anyway, great work @johlrogge! I really like your approach, and agree that it's probably more the AMD way to do it that way. If you'd be interested in codifying it as a plugin that would be awesome. I can update this page: https://busterjs.org/docs/extensions/ to include what you need to know, I think we have all the API support you'd need to codify your approach.

I'm thinking: Configure buster like this:

config["web-module"] = {
    environment: "browser",
    extensions: ["buster-amd"],
    rootPath: "../web/resources/public/",
    libs: ["js/require-jquery.js"],
    tests: [
        "test/**/*.js"
    ],
    resources: ["**/*.js"]
}

The plugin will:

  1. Provide the buster module (like you specified it).
  2. Force autoRun to false.
  3. Generate the "all tests" meta package.

I like being specific in the config about what tests are to run. The plugin will use this information to build the meta package, but will remove them so they don't actually load. In code this means something along these lines:

var Path = require("path");

module.exports = {
    configure: function (config) {
        var testsToLoad, rootPath;

        config.on("load:tests", function (tests, rp) {
            rootPath = rp;
            testsToLoad = tests.slice();
            while (tests.length > 0) {
                tests.shift();
            }
        });

        config.on("load:resources", function (resourceSet) {
            testsToLoad.forEach(function (path) {
                resourceSet.addFile(Path.join(rootPath, path), {
                    path: path
                });
            });

            resourceSet.addResource("/load-all.js", {
                content: "Load all stuff here"
            });

            // Add buster module

            resourceSet.appendToLoad("/load-all.js");
        });
    }
};

I will complete my work on the async suites too, but I really dig this approach for the AMD tests.

@johlrogge

This comment has been minimized.

johlrogge commented Dec 20, 2011

I'm glad you like it. It is really encouraging!
Of course I want to codify this as a plugin. I'll get cracking at it.
I'll call the module buster-amd? (or is it requirejs specific?).

You will want to check my javascript code though :) I am a java/scala programmer mainly so I'm not too comfortable with javascript yet. I guess I'm saying, don't be shy with your comments about how my code can be improved. I know my skill is lacking and want to learn more.

@cjohansen

This comment has been minimized.

Member

cjohansen commented Dec 20, 2011

Sure, we'll guide you through it :) I guess you can start it off as buster-requirejs, and we'll dub it buster-amd if it's possible to make one generic enough solution. I think so, but I'm not AMD-capable enough myself to say :)

@geddski

This comment has been minimized.

geddski commented Dec 21, 2011

@johlrogge great job, that was a clever idea! I replicated it locally as well. Just a couple of things we should consider:

Order:

The tests won't run in the same order every time. RequireJS loads dependencies async but guarantees no order (unless you use the order! plugin, which is kind of a hack). So if your all-test.js looks like this:

require(["lib/r-buster", "test/module-1", "test/module-2", "test/module-3"],
    function(buster) {
        buster.run();
});

sometimes module-1 will load first, sometimes module-3, etc. The order is as good as random. This shouldn't be a big deal for most people, especially since your tests are supposed to be independent of each other. But if you're using a certain reporter and want things to appear in the same order each time the tests are run you'd be out of luck. The reason RequireJS does this is so it can load the scripts in parallel, which is great for performance in the browser. If you want to guarantee the order of the tests you'd have to do this:

require(["require", "lib/r-buster"], function(require, buster) {
    require(["require", "test/module-1"], function(require){
        require(["require", "test/module-2"], function(require){
            // at this point we know all submodules has been loaded
            buster.run();
        });
    }); 
});

It's not super pretty, but it loads the scripts in order (and serially) just like regular script tags in an HTML page do. Downside is the tests may run slightly slower in the browser. But like I said, it's probably not an issue.

Config:

Like @cjohansen pointed out, there's something awesome about specifying what tests to run in the buster.js config file. If all-test.js could be generated from that config, that would be sweet indeed.

Great work! Let me know how I can help with the extension.

@johlrogge

This comment has been minimized.

johlrogge commented Dec 21, 2011

@GEDDesign Thanks!

I forgot to agree with Christian but his idea about dynamically generating the loader-module (all-tests) is just awesome. If it is dynamically generated it doesn't matter if it is ugly or verbose so we can use your strict ordering technique either as the norm or optional. I agree that one may want reporting to look pretty even if you have independent tests.

I have started a project and basically just created a module for it. That is I have all the boilerplate in place. I have also started to study buster-configuration since it seems that is what the plugin will make modifications to.

I guess I can just create a git repo o github that we can colaborate in until it is mature enough to make it into buster. Or, if I get access to some module repo either here or on gitorious would also work for me. Right now I have one locally on my machin so I just need to add a remote once one exists.

@magnars

This comment has been minimized.

Member

magnars commented Dec 21, 2011

FYI Buster actually runs your tests in random order. Just so you don't rip your hair out in frustration testing the strict ordering technique above. :-)

@johlrogge

This comment has been minimized.

johlrogge commented Apr 5, 2012

@spencercarnage weird. I would have to look into that. We talked before about the possibility to specify what command the AMD-plugin should use to require modules. For instance in curl the command is not require but curl. The AMD specification does not specify what the "top level" require should be named or how it should be invoked, only how modules are defined and how modules can require dependencies.

From a quick look at requirejs site it looks like require has not changed how this works. I had a similar issue but I just specified require as a library for buster to load by adding libs: 'require.js' to my buster.js file

@johlrogge

This comment has been minimized.

johlrogge commented Apr 5, 2012

.@cjohansen Have you been able to reproduce that tests are sometimes not run using the tests I provided? (Or are you still unpacking stuff? I moved over a year ago and I'm not done :P))

@cjohansen

This comment has been minimized.

Member

cjohansen commented Apr 7, 2012

@johlrogge moving is now mostly complete :) Had a couple of weeks of stomach flu with the kids and all though...

Anyway, I've reproduced the errors, and I'm looking into them. @GEDDesign In order to support require like you're using it, we'd have to wrap it in the amd extension. Without the extension, you'll have to nest it correctly with the run callback for it to work. I'm also looking into the plugins issue. Once again sorry for moving slowly.

@cjohansen

This comment has been minimized.

Member

cjohansen commented Apr 8, 2012

Alright, getting there. I fixed the plugins issue. Turns out this test is the only one that did anything of interest asynchronously, causing the intermittent failures. The reason was timing issues - for some runs the test runner started (and finished) before the async context was completely added to the queue. This is a bug, and showed me that I had not carried the async test cases/specs through all the way.

busterjs/buster-test@4352ce1
busterjs/buster-test@98cc7e4

These two commits make the entire chain asynchronous, so the test runner can no longer start running half-way through defining an asynchronous test case/spec.

Only missing issue at this point is a require wrapper in the AMD wrapper. Not entirely convinced that's a good idea. Any takers?

@johlrogge

This comment has been minimized.

johlrogge commented Apr 8, 2012

Nice work. I will have to think more about the requre wrapper. One good thing with a wrapper is the ability to inject stubs for some modules. The downside is that it opens up a host of potential issues if we fail to make a "watertight" wrapper.

I will check out and try the latest busterjs tomorrow. Really looking forward to seeing my suites run reliably :)

@johlrogge

This comment has been minimized.

johlrogge commented Apr 9, 2012

I've pulled the latest and greatest using the dev-script but still get intermittent skips of tests. It seems to be some improvements though: It always runs something but not always everything?
To tired to investigate more atm. Will try to find the time during the week to isolate the issue I'm experiencing wether it is some dependency I messed up or something in buster.

@lockenj

This comment has been minimized.

lockenj commented Apr 10, 2012

I am having some difficulties trying to utilize the buster-amd extension... I am pretty sure that the problem is me being a NOOB when it comes to node, but just in case ;)

#This is what I did attempting to install/use the buster-amd extension

I'm running Ubuntu 11.10...

  1. I installed npm

  2. I installed the dev tools using
    npm install -g buster-dev-tools

  3. I then setup my .bashrc
    NODE_PATH=/home/Buster-Dev-Tools
    PATH=/home/Buster-Dev-Tools/buster/bin/:

  4. I then cloned buster-amd into /usr/lib/node_modules
    git clone https://github.com/busterjs/buster-amd.git buster-amd

  5. I then ran buster static from /usr/lib/node_modules/buster-amd/demo/lab

  6. When I point chrome to it I get this error in the developer tools console

    Uncaught TypeError: Object # has no method 'run' (anonymous function)load-all.js:3
    req.execCbrequire-jquery.js:1660
    execManagerrequire-jquery.js:426
    maprequire-jquery.js:527
    execManagerrequire-jquery.js:504
    maprequire-jquery.js:527
    execManagerrequire-jquery.js:504
    mainrequire-jquery.js:803
    callDefMainrequire-jquery.js:814
    context.completeLoadrequire-jquery.js:1313
    req.onScriptLoadrequire-jquery.js:1707

    I think what I am the most confused about is how buster knows about buster-amd.js and its life-cycle.

@lockenj

This comment has been minimized.

lockenj commented Apr 11, 2012

Ok sorry to bore you all with my nodejs learning pains... I spent last night going through nodejs tutorials and feel like I have the 10,000 foot view of it. I went back this morning and looked through the buster-dev-tools & buster-amd projects with a new light.

If I execute the buster-amd/demo/lab test using buster server and buster test it works correctly. If I try and execute it via buster-static I still get the above error due to the buster object not containing a "run" method inside load-all.js.

I'm going to spend today attempting to familiarize myself with the buster code base and try and figure out the differences between running buster-static and buster-server/buster-test.

@johlrogge

This comment has been minimized.

johlrogge commented Apr 11, 2012

Hi Jacob,

I had the same issue with buster static. Apparently buster static needs
some more love before it works properly.
Try buster server and capture a browser instead

  1. buster server
  2. surf to localhost:1111 and capture the browser
  3. buster test

Sorry for not getting back earlier and saving you the pain. Also with
buster AMD make sure you run the latest code from the repository and not
npm. It still hasn't quite settled and I still have some issues with it not
picking up all my tests reliably ATM.

It would be excellent to hear if you get similar issues or if it works for
you.

/J

@lockenj

This comment has been minimized.

lockenj commented Apr 12, 2012

@johlrogge thanks for the help... I'm now all setup properly and looks like I have the same issue (buster not picking up my tests), except it never picks the tests up. So I forked your repo and added a backbone/requirejs sample under your demo directory. Seeing how this is reproducing the issue every time I thought it might be useful.

https://github.com/lockenj/buster-amd

However I didn't get much time yesterday to familiarize myself with the buster code base/architecture so I don't think I will be very helpful in resolving the issue.

Hope I'm helping and not just stirring the pot.

@lockenj

This comment has been minimized.

lockenj commented Apr 12, 2012

I also attempted changing my user-model-test.js around to use the BDD style and its also does not pickup any tests that are declared within the AMD callback. I added a garbage test outside of the requireJS define callback closure and its picked up every time.

@lockenj

This comment has been minimized.

lockenj commented Apr 13, 2012

Ok I don't think the problem I am encountering is a buster-amd issue at all. If I simply add in a delay before I call describe Buster will not pickup the test.

setTimeout(function(){
    describe("DelayedTest", function(){
        it("should pass", function() {
            expect(true).toEqual(true);
        });
    });
},93);

I'm sure the timing is different for everyone but if I have the timeout take less than 93 milliseconds the test is found and executed; 93 or greater and the test is overlooked.

@johlrogge

This comment has been minimized.

johlrogge commented Apr 13, 2012

The timeout experiment can't work. If you wan't to delay a test you
will have to make sure that you block for some time before you return
execution. I don't know exactly how buster collects information for a
testrun but it is significant that all tests are created before "run"
is called which is usually done hooking in to window.onReady (or
whatever it was called) or in the case of buster AMD it is called from
the generated "main" module that depends on all the testmodules. In
the AMD case the AMD loader (such as requirejs) guarantees that all
submodules have been loaded before the main module is created with
those dependencies. If you define tests using a timeout in a submodule
the definition will (depending in the length of the timeout typically)
happen after the main module is created (and there will be no created
tests for buster to be found when the run method iss called by the
main module)

Just to make sure:

  1. are you running the latest code (not only buster-amd, all of
    buster) checked out from git, not installed via npm?
  2. did you try @geddesigns's demo project mentioned earlier in this thread?

If you didn't do 1 then it is less surprising that there are problems.
If after doing 1 doing 2 finds no tests it is very interesting. There
are some expected failures in 2 (when a test is defined inside a
require([], function(){...}) but other than that they should work.

Hope this helps some
/J

@cjohansen

This comment has been minimized.

Member

cjohansen commented Apr 13, 2012

So we solved @lockenj's issues on IRC. Even found a bug in buster-test-cli that is now solved.

buster-static is not AMD-ready, we'll tackle that later.

@johlrogge I'm now seeing a discrepancy between runs as you said, so I'm investigating. Seems that the plugin test is only occasionally being run.

@tkellen

This comment has been minimized.

tkellen commented Apr 13, 2012

Just chiming in to say thanks for all the work you guys are doing--I cannot wait to start using Buster on my AMD projects!

@cjohansen

This comment has been minimized.

Member

cjohansen commented Apr 13, 2012

@tkellen thanks :)

@johlrogge Ok, I think I've solved it now. Seems there was a bug that caused every async describe to be pinged back twice - only the second ping-back would sometimes go in to slow for the runner to wait. Before I fixed that I was seeing 11 test cases and 12 test cases on and off. Having fixed that bug I consistently see 6 test cases, which is the right number. Can you test and confirm? Maybe can close this issue soon? :)

@johlrogge

This comment has been minimized.

johlrogge commented Apr 13, 2012

@cjohansen Thanks for looking working so much on this issue. I wish I would have had more time to help out but I didn't.

I just updated to the latest code and it looks very promising. I have to find the time during the weekend to go through my test suite to see that everything I expect to be there is actually in the run but right now it looks like it might actually be solved.

Nice work and thanks for sticking with this issue, moving, stomach flu and all!

@lockenj

This comment has been minimized.

lockenj commented Apr 13, 2012

HUUUGE thanks @cjohansen @johlrogge @augustl for helping me come up to speed on Buster and adding this capability into the system, just awesome!

@cjohansen I was able to resolve the backbone dependency issue (https://github.com/lockenj/buster-amd/commit/e79207d9d4991df47e303e0c989cddb83dda26df). I was going to use the amd versions of underscore and backbone (https://github.com/amdjs/underscore and https://github.com/amdjs/backbone) but they were a version behind, so I decided to make it work just in case I needed the latest and greatest.

@johlrogge do you think this backbone demo would be helpful for others inside the buster-amd repo???

Thanks again everyone your guys rule!!!

@jontore

This comment has been minimized.

jontore commented Apr 15, 2012

Hi.

I've been testing out the buster-amd module the last few days, and run into some issues when it comes to path resolving.

In our app we're using require-js with relative paths, this seems to be an issue with the buster-amd. I had to set a static baseUrl in all the tests and the modules that required through require-js. This means that I basically have to use the full-path in all my js files, which feels weird. Any suggestions to a good work around for this? Is there a way to tweak the file resolving?

@cjohansen

This comment has been minimized.

Member

cjohansen commented Apr 16, 2012

@jontore can you provide a minimal reproducible case for this? I'm not totally getting what you're problem is. And I have seen relative paths work before.

@johlrogge

This comment has been minimized.

johlrogge commented Apr 17, 2012

@cjohansen I think the issue is when the tests and the source don't share the same root and the source nodules in turn require submodules via relative paths. Then the first sourcemodule can be found from the test using a relative path but the submodule can not be found from the sourcemodule sine the root is not the same.
The work around is to add some require configuration in the test-module to say that it's root should be in the sourcefolder. The other workaround is to simply make sure test and source share the same root.

It would be good to be able to be able to configure the source root already in the loader module via buster.js for instance (most likely the source root is what you want). The problem to solve is that requirejs and curl have different ways of configuring the root folder. I have some ideas about this but I would have to find the time. I am preparing a presentation for monday and migrating to a new computer at the same time. At the moment I know more than I ever wanted to know about aliging partitions on SSD's and why you want to do that (and why some think that it is not needed on modern SSD's) so it's moving kind of slowly :)

@johlrogge

This comment has been minimized.

johlrogge commented Apr 17, 2012

@cjohansen I think we can maybe live with this (slightly) annoying shortcoming for now?

@cjohansen

This comment has been minimized.

Member

cjohansen commented Apr 18, 2012

@johlrogge thanks for the explanation. I agree, this is something we can live with for now. In any case, the async support in buster is now good enough. Further improvement can be applied directly to the buster-amd extension. Let me know when you have time to huddle on the relative paths issue and I'll be happy to help.

Magic moment: closing this issue :) thanks everyone for pitching in and helping out. Please report any further issues as new ones.

@cjohansen cjohansen closed this Apr 18, 2012

@geddski

This comment has been minimized.

geddski commented Apr 18, 2012

Thanks everyone! Fantastic group effort. I'll miss you #15.

@cjohansen

This comment has been minimized.

Member

cjohansen commented Apr 18, 2012

:)

@briancavalier

This comment has been minimized.

briancavalier commented Apr 18, 2012

Awesome. Thanks everyone! Can't wait to try this out.

@tkellen

This comment has been minimized.

tkellen commented Apr 19, 2012

Thanks guys! I'm hoping to give this a whirl later this week.

@johlrogge

This comment has been minimized.

johlrogge commented Apr 19, 2012

Thanks everyone! Feels great that buster-amd is finally usable. Looking forward to hear what experiences people will have with it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.