Get help with testing, discuss unit testing strategies etc.


Post by mberrie »

Hi!

We are currently evaluating Siesta for running integration tests on our ExtJs application (running 4.1.2a).

We are experiencing instabilities when running some tests on Google Chrome (tested agains v24 and v27 on Windows 8 x64). At one point the test unexpectedly loads the Siesta UI into the sandbox iframe. The test case will then fail at the next condition because obviously the application (and its DOM) are no longer present.

This only happens on Chrome but *never* on Firefox.

Also, it does *not* happen on the first run of the test after the initial load of the Siesta UI.

When stepping through the code in the debugger, the loading of the Siesta UI into the iframe happens at some point inside the obfuscated Siesta code base.

Please advise! Thx.

Post by mats »

Can you isolate this into a simple test case we can run and inspect?

Post by nickolay »

Can you check that you do not include "siesta-all.js" in your preload files? There's no need to load siesta in the preloads and in the same way do not include your application files in the "harness.html" file.

Post by mberrie »

@nickolay
I verified again, and it's not the case.

@mats
The best I can offer so far is the following:

The iframe reload only occurs when using Ext's dynamic loading (Ext.Loader). The problem does *not* occur when we load all additional class files as one (minified) bundle.

I should also mention that we use a custom bootstrap loader to load ExtJs core asynchronously. In debug mode we then configure Ext.Loader to load the individual source files (both for ExtJs and our custom app classes). In 'production' we load both ExtJs core plus the bundle via this bootstrap loader.

In debug mode, usually some of these files are loaded synchronously, but for the sake of ruling that out as a problem I have now a test case where all files are loaded asynchronously (that is Ext.Loader uses script tags to load the files instead of XHR). No change.

I also eliminated our custom siesta test class and 'inlined' all code into the test case file. No change.

After I did this last change (and actually before 'fixing' the Ext.Loader synchronous loading), I noticed that when I halted execution via a breakpoint just before the statement that causes the iframe reload, the test case runs through fine. This is a change to from before I applied that change (the 'inlining'). Therefore it seems that the issue might be timing related.

And I found another oddity:

Here is the code fragment where the reload occurs.
...
function(next) {
    var field = t.getExt().ComponentQuery.query('#myfield')[0];
    t.type(field, 'text', function() {
        t.ok(true, 'anonymous function entered');
        next();
    });
},
...
Execution enters and leaves t.type, and here is the weird thing: a breakpoint inside the anonymous function is never triggered (chrome debugger never halts), however, the debug output is logged in siesta and the test case fails at the next chain entry.

I still have to see if I can isolate a test case with standard components. But I am not sure I will find the time to do that. This has already cost me a couple of hours. I hope you guys can pick up from here.

Maybe you can provide some background info what this could be related to in case you ever experienced that kind of oddity (iframe reloads, chrome debugger breakpoints not hit) before.

Another side note: is this some kind of Chrome crash that happens? When I check the iframe src attribute it still points to the correct hostPageUrl.

Post by mats »

Hmm, this sounds very weird. To be able to help a test case would be the best, or if you can setup remote access to your machine so we can inspect this live?

Post by mberrie »

Thank you for the offer to look into it, but at the moment I cannot make either (remote access, test case) happen.

We will continue to evaluate with Firefox, and maybe come back to looking into the Chrome issue later.

I have also at least one other issue on Chrome which I could track back to a deferred load call in Ext.data.Store - so at least this one issue seems timing related.

Post by alfonso.nishikawa »

Hi!

Any update on this? I am experiencing the same.

Thank you!

Post by nickolay »

Hi,

Please start a new thread for the issue and provide more details - we'll look into it.

Post by alfonso.nishikawa »

Hi, @Nickolay.

Fixed! :D It was my fault. I was doing "Ext.history.back()" when login in to get to the previous page. I changed it to a fixed route with redirectTo() and that fixed it :)

Thank you!

Post Reply