Get help with testing, discuss unit testing strategies etc.


Post by AaronTovo »

I get this message
Ext.onReady took longer than 10 seconds - some dependency can't be loaded? Check the 'Net' tab in Firebug
every time I run a test.

I don't see any error messages in Firebug, or any other browser tool. And all of the tests complete successfully. I've tried adding more files to the list of pre-loaded files in Harness.configure but it doesn't make much difference.

There's one serious side effect to this error: the test takes 10 seconds to run even if it's just 010_sanity.t.js!

What is the cause of this?

In case it helps, here is the list of pre-loaded files I currently have:
        "siesta-test/lib/ext4/resources/vitaltheme/css/vitaltheme.css",
        "siesta-test/lib/ext4/ext-all-debug.js",
        "siesta-test/lib/siesta-1.0.8-lite/siesta-all.js",
        "siesta-test/lib/ext4/locale/ext-lang-en.js",
        "study-search/Utils.js",
        "study-search/model/Archive.js",
        'siesta-test/010_sanity.t.js',
        'siesta-test/020_basic.t.js'
I know the two test files at the end are not necessary, but I was trying to eliminate any possibility. :|

Post by mats »

It'd be a lot easier if you can just submit a full test case, that's what Siesta is for :)

Post by nickolay »

This message means that dependency of some class can not be loaded. Check the "Net" tab in Firebug - it should mark the failed HTTP requests (404 error) in bold red.

Post by AaronTovo »

I looked for 404 errors and other errors in the Net tab and the console in Firefox, Chrome and IE9. There are none.

Below is the code for test itself. All of the assertions pass.
StartTest(function(t) {
    t.diag("Sanity Test, loading classes on demand and verifying they were indeed loaded.");

    t.ok(Ext, 'ExtJS is here');
    t.ok(VI, 'VI namespace is here');
    t.ok(TR, 'TR strings are here');

    t.requireOk('StudySearch.model.Archive');

    t.done();   // Optional, marks the correct exit point from the test
})
And this is the harness configuration in index.js:
var Harness = Siesta.Harness.Browser.ExtJS;

Harness.configure({
    title       : 'Awesome Test Suite',
    loaderPath  : { 'StudySearch' : 'study-search' },
    waitForAppReady: true,
    preload     : [
        "siesta-test/lib/ext4/resources/vitaltheme/css/vitaltheme.css",
        "siesta-test/lib/ext4/ext-all-debug.js",
        "siesta-test/lib/siesta-1.0.8-lite/siesta-all.js",
        "siesta-test/lib/ext4/locale/ext-lang-en.js",
        "siesta-test/TR.js",
        "study-search/Utils.js",
        "study-search/model/Archive.js",
        'siesta-test/010_sanity.t.js',
        'siesta-test/020_basic.t.js'
//        'siesta-test/030_archive.t.js'
  //      "study-search/StudySearchApp.js"
    ]
});

Harness.start(
    'siesta-test/010_sanity.t.js',
    'siesta-test/020_basic.t.js'
//    'siesta-test/030_archive.t.js'
);

Post by nickolay »

Some corrections:

`requireOk` is async operation (triggers Ajax call) - need to provide a callback for it and continue the test in the callback:
    StartTest(function(t) {
        t.diag("Sanity Test, loading classes on demand and verifying they were indeed loaded.");

        t.ok(Ext, 'ExtJS is here');
        t.ok(VI, 'VI namespace is here');
        t.ok(TR, 'TR strings are here');

        t.requireOk('StudySearch.model.Archive', function () {
            t.done();   // Optional, marks the correct exit point from the test
        });        
    })
Btw, later you are including StudySearch.model.Archive in the preloads - this defeats the purpose of `requireOk` (which checks that class can be dynamically loaded).


There's no need to include siesta or test files in the preload:
    var Harness = Siesta.Harness.Browser.ExtJS;

    Harness.configure({
        title       : 'Awesome Test Suite',
        loaderPath  : { 'StudySearch' : 'study-search' },
        waitForAppReady: false, // try setting this to false
        preload     : [
            "siesta-test/lib/ext4/resources/vitaltheme/css/vitaltheme.css",
            "siesta-test/lib/ext4/ext-all-debug.js",
            "siesta-test/lib/ext4/locale/ext-lang-en.js",
            "siesta-test/TR.js",
            "study-search/Utils.js",
            "study-search/model/Archive.js",
        ]
    });

    Harness.start(
        'siesta-test/010_sanity.t.js',
        'siesta-test/020_basic.t.js'
    //    'siesta-test/030_archive.t.js'
    );
It seems also you are using "waitForAppReady : true" option, but in first test there's no instance of Ext.app.Application involved - may be that is the reason. Try setting it to false.
You can also specify various options for a single test:
    Harness.start(
        {
            url : 'siesta-test/010_sanity.t.js',
            waitForAppReady : false
        },
        ...
    );

Post by AaronTovo »

Ah! Thanks! Adding the callback and setting waitForAppReady to false fixed the problem (both were necessary).

I knew that preloading those files was unnecessary, but at one point I had put all of the files in that list in a vain attempt to address this "10 second" problem. Same with setting waitForAppReady to true - I was trying all kinds of things and probably making the problem worse. Growing pains. :|

Post by AaronTovo »

One follow up question...

Is there a recommended idiom for running multiple requireOK() calls?

One way to do it would be
    t.requireOk('StudySearch.model.Archive', function () {
        t.requireOk('StudySearch.store.Archives', function () {
            t.done();   // Optional, marks the correct exit point from the test
        });
    });
which works fine, but the indentation could get pretty deep if you have a lot of files and I think that isn't as elegant as I'd like.

The other way I thought of was to do
    t.requireOk('StudySearch.model.Archive', function () {});
    t.requireOk('StudySearch.store.Archives', function () {});
which works, but only if I leave off the t.done(); at the end of the test. Adding t.done() results in that message that says something like 'Added assertions after the test has finished.'

Post by nickolay »

Ah, great. Actually this is a small bug - it should been advising you to disable the "waitForAppReady" option instead of checking the "Net" tab. Fixed, thanks!

Post by nickolay »


Post by AaronTovo »

Just what I was looking for. :)

Post Reply