Get help with testing, discuss unit testing strategies etc.


Post by jminutella »

Hi,

I'm kinda scratching my head at this one. I have some tests that essentially do the following...

1. Logs into the app
2. Clicks on a tree node to open a view
3. Checks the itemId of the panel to see if it matches and is visible (waitForCQVisible)

It works perfectly when I run the test suite in the browser. However, when I run it in the command prompt with the --headless flag, I get time outs with the Waiting aborted error message.

I'm thinking maybe it has something to do with finding the tree nodes? I've tried increasing timeouts, restructuring some code and still hasn't helped. The common thread is that I'm searching for tree nodes to click on.

Any idea?

Thanks.

Post by nickolay »

Hi,

What if you run it in automation, but not headless? I assume we are talking about Chrome?

You mentioned it fails with "waiting aborted" - thats for CQ visible? What if you wait just for CQ (component created), then some timeout (lets say 2s) and then use `t.diag()` to report some info about the component's element (for example if its a top element, using https://www.bryntum.com/docs/siesta/#!/api/Siesta.Test.Element-method-elementIsTop )

My guess is, that some subtle environment difference causes your app to be rendered differently.

Also worth trying taking screenshot of the test page (t.screenshot).

Post by jminutella »

My environment is just my Windows 10 workstation. After I posted this, I updated my ChromeDriver to version 80 to match Chrome.
What if you run it in automation, but not headless? I assume we are talking about Chrome?
Yes Chrome, sorry. It does seem to work in Automation mode. This is also my last test so I'm not sure if that has anything to do with it either.
`t.diag()` to report some info about the component's element (for example if its a top element,
Would I place t.diag() in the callback for the t.waitforCQVisible?

The screenshot didn't work either.

Here's what I'm seeing:
siesta_timeout.PNG
siesta_timeout.PNG (45.14 KiB) Viewed 4107 times
Also - here's the test case in question. Again - super weird how this doesn't work with the --headless param
describe("Launch Pending Changes", function (t) {
    t.it('Should open Pending Changes from the Views pane', t => {
        t.chain(
            t.connect(),
            t.isJssInfoViewLoaded(),
            { click : '#ViewsPane treeview => .x-tree-node-text:textEquals(Pending Changes)', desc: 'Should click the Pending Changes node in the Views Pane' },
            { waitForCQVisible : '#AppTabPanel #connectionCenterRegion panel[itemId=PendingChanges]', desc: 'Pending Changes should be opened and currently visible',
                callback: function () {
                    t.diag();
                }
            },
            { waitFor : 20000 },
        
            { screenshot : { fileName : 'screenshots/screenshot.png', compareWithPrevious : true } },
        );
    });
});


Post by jminutella »

Alright so I figured it out - I just had to write a function to programmatically select the node in the tree and the waitForCQVisible works fine.

Kinda bummed I had to do it this way as I thought I could've just used the Ext JS methods you guys supply but it is what it is.

Thanks for your help tho!

Post by nickolay »

Glad you figured it out, would be good to understand why it was happening though.

The last similar issue I recall was - the test was failing in puppeteer headless, because in puppeteer headless, for some reason, Chrome switches to the "invisible, on-demand" scrollers (like on Mac) and test had some hardcoded coordinates.

Looking on the code and the workaround you found, it seems this click
{ click : '#ViewsPane treeview => .x-tree-node-text:textEquals(Pending Changes)'
does not do what it is supposed to do.
Try something like this may be:
{ moveCursorTo : '#ViewsPane treeview => .x-tree-node-text:textEquals(Pending Changes)' }
{ screenshot : { fileName : 'screenshots/screenshot.png' } },
{ click : '#ViewsPane treeview => .x-tree-node-text:textEquals(Pending Changes)' }
The initial "moveCursorTo" is supposed to scroll the element into the view and make it accessible for clicking. Then a screenshot may be will provide some information.

Post Reply