Tests keep running although they are done (t.click()?)

[carina]

Hi,

I'm having problems to get all tests to show up as finished, instead they are displayed as still running. This is a sample test case:

StartTest(function (t) {

    t.waitForCQ('somecomponentwithabutton', function (somecomponentwithabutton) {
        t.diag("somecomponentwithabutton has been loaded.");

        var myButton = somecomponentwithabutton[0].down('button');
        t.ok(myButton, "myButton has been found");

        t.click(myButton, function () {
            t.diag("myButton has been clicked");
            t.waitForCQ('someresultcomponent', function (someresultcomponent) {
                t.ok(someresultcomponent, "someresultcomponent has been found");
                t.diag("Test should be done now");
                t.done();  //just in case; doesn't change anything, no matter if "needDone" is set to true or false
            });
        });
    });
});

The results all show up correctly, up until the final "Test should be done now" message which should be the end of the testcase. The icon of the testcase is however set to lightning png (tr-status-running, not tr-test-status-working) and if I set maxThreads to 1 then the next test will not be started until the current test times out.

It might be related to t.click because if I run only the first part it works fine and is completed successfully:

StartTest(function (t) {
    t.waitForCQ('somecomponentwithabutton', function (somecomponentwithabutton) {
        t.diag("somecomponentwithabutton has been loaded.");

        var myButton = somecomponentwithabutton[0].down('button');
        t.ok(myButton, "myButton has been found");
    });
});

I'm using the hostPageUrl option at the moment, in case that is relevant, and Siesta 1.0.8.

Do you have any ideas what might be causing this?
Thanks!

Carina

[mats]

Hmm, doesn't ring any bell. Could you post a complete simple test case?

[carina]

I tried to make a sample based on the existing Siesta examples but I couldn't reproduce the problem there so it seems to be related with loading my more complex application via the hostPageUrl option. However, I discovered that if I set overrideSetTimeout:false then the test case is finished successfully (all messages until the last one are displayed and the test is marked as passed).

I will combine that with needDone:true and as far I understood the documentation this should ensure that only successful tests are marked green (I would however still like to understand what is happening here).

Unfortunately, I'm also having another issue: when I run a test with the HTML view visible on the right side, it is executed correctly (button is found & clicked and it triggers the corresponding action). If I collapse the view or if I run multiple tests at once, there seems to be a problem with the button click (no action is triggered). When running multiple tests at once I can see that the test switches to the currently running test and there is a simulated mouse click visible as a red circle. This mouse click is however not executed on the correct position of the button. Instead, the mouse is clicked at a different position (x+100, y+100px or something like that). It looks as if the position of the button was calculated incorrectly. This results in the button not really being clicked and prevents the further test logic from running.

Do you have any ideas what that could be about? Otherwise I'll try to create a complete sample to reproduce it.

[mats]

Which browser?

[carina]

Chrome and Firefox on OS X.

I also tried getting and setting the click position manually but that didn't help either. The calculated position that is displayed in the test result is correct (x=15, y = 100) but the position that is actually clicked is a different one (x=100, y=150 or something like that).

    var pos = myButton.getPosition();
        t.diag("button position: " + pos[0] + "/" + pos[1]);

        t.click(pos, function () {// do stuf... });

[jakub]

Do you maybe have firebug/dev tools opened when running tests ? It may cause wrong cursor position calculation.

[nickolay]

@carina

About your initial problem - for convenience, Siesta overrides `setTimeout` in the scope of test, so you don't have to do "t.beginAsync/endAsync" for each "setTimeout". However, if your application (or library used in application) uses some sort of infinite polling:

var func = function () {
    setTimeout(func, 100)
    
    // do something
}

func()

This will make siesta think that test is running infinitely. Setting "overrideSetTimeout" to false helps. The partial solution will be to restore the "setTimeout" in the "t.done()" - adding this to todo list for next release.

About incorrect click position - do you use iframes in your application? If so is the button inside of iframe?

[carina]

Thanks for your replies!

@nickolay We're not using infinite polling and there are also no requests that are still running (that was the first thing I checked). But maybe there is something that I'm overlooking. As long as overrideSetTimeout works, I'm happy for now and will keep an eye open for the possible cause of this.

About incorrect click position - do you use iframes in your application? If so is the button inside of iframe?

No, there is no iframe except for the one that is created by Siesta. There is some nesting going on (Viewport with border layout => TabPanel => Panel with anchor layout that contains the button) but nothing out of the ordinary.

@jakub:

Do you maybe have firebug/dev tools opened when running tests ? It may cause wrong cursor position calculation.

I disabled Firebug and the developer tools in Chrome were not open either but the problems persists. I also tried not to move my mouse at all while the tests are running but that didn't change anything either.


What I noticed is that the behavior of the right/HTML view panel is not consistent. Sometimes it will e.g. show the content of the first testcase although the later tests are already running. Sometimes it will show the content for the second test case and stop at this point (in this case, the second test case is executed successfully since everything works fine as long as the HTML view is visible while the button is being clicked).

This is interesting since I tried to change the settings so that the behavior is as consistent as possible: overrideSetTimeout:false, keepResults:false, maxThreads:1, runCore:"sequential".

I guess there is no siesta-all-debug.js file available? Otherwise I would have tried to find out what is going on by debugging into the source code.

[mats]

siesta-all.js is fully readable and free. Download on main Siesta page

[carina]

Oh, thanks for the hint! I had downloaded the Standard trial version and that came with the compressed code. I'll use the Lite instead for now and let you know if I'm able to find out where the problems are coming from.