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.
Support Forum
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).
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).
Read the API documentation
My environment is just my Windows 10 workstation. After I posted this, I updated my ChromeDriver to version 80 to match Chrome.
The screenshot didn't work either.
Here's what I'm seeing: Also - here's the test case in question. Again - super weird how this doesn't work with the --headless param
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.What if you run it in automation, but not headless? I assume we are talking about Chrome?
Would I place t.diag() in the callback for the t.waitforCQVisible?`t.diag()` to report some info about the component's element (for example if its a top element,
The screenshot didn't work either.
Here's what I'm seeing: 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 } },
);
});
});
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
does not do what it is supposed to do.
Try something like this may be:
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.
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)'
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)' }
Read the API documentation