Get help with testing, discuss unit testing strategies etc.


Post by klodoma »

I am playing around with your trial webdriver and I have noticed a problem.

I created a docker container where I want to run the tests but they fail if I run them in the a docker container.
If I run the tests on a unix host similar to the docker container all good.

I am getting preload errors "fail 1 - Preload of https://127.0.0.1:88/build/js/shared.js has failed". It seems like in the docker container something is going wrong. Some other times, some other errors are displayed. The errors are not consistent.

In both cases, the docker container is providing all the files for the tests. (port 88:88 is mapped).
Attached are screenshots from the 2 hosts(one is the main host, the other one is the docker container - this fails)

PS: I am playing around with siesta-5.3.2-trial. webdriver--version is in the screenshot for both host/docker

Any ideas?
Attachments
Screenshot_41.png
Screenshot_41.png (101 KiB) Viewed 4998 times
Screenshot_40.png
Screenshot_40.png (217.77 KiB) Viewed 4998 times
Screenshot_38.png
Screenshot_38.png (235.96 KiB) Viewed 4998 times

Post by nickolay »

Hi,

Hard to say, the preload failure indicates its a legitimate 404 error, detected by browser and reported by Siesta. Possibly a file is just missing? or some access directives in the webserver aren't correct?

Can you try reproducing this error with Siesta 5.3.1 ?

Post by klodoma »

nickolay wrote: Sun Mar 22, 2020 12:27 pm Hi,

Hard to say, the preload failure indicates its a legitimate 404 error, detected by browser and reported by Siesta. Possibly a file is just missing? or some access directives in the webserver aren't correct?

Can you try reproducing this error with Siesta 5.3.1 ?
No files are missing. I thought so too initially. In the tests that pass (the webdriver is on the server(not in the docker)) but the rest is delivered by the docker container.

I didn't tested with 5.3.1. A few months ago when I tried the CI setup with docker it worked well (I think it was the 5.2.3, I have to check).

Another thing I have noticed is that ALWAYS the second preload file fails. So no matter how I order these, it's always the second file that fails.
let preload = [
    '/build/runtime.js',
    '/build/js/shared.js',
    '/build/js/common.js',
    '/build/js/testing.js'
];

project.configure({
    viewDOM: true,
    mouseMovePrecision: 100000,
    preload: preload,
    ...
Is there a way to debug the console.log of the browser? or even the network requests of the browser?

Post by nickolay »

Another thing I have noticed is that ALWAYS the second preload file fails. So no matter how I order these, it's always the second file that fails.
This sounds very weird, the order of preloads shouldn't matter of course.
Is there a way to debug the console.log of the browser? or even the network requests of the browser?
This is possible with puppeteer (if error is reproducible with puppeteer launcher). The puppeteer's `Page` event has various request/response related events, which can be logged I guess: https://devdocs.io/puppeteer/index#event-request

You will need to modify "bin/siesta-launcher-all.js" for that, search for:
            this.puppeteerPage.on('console', msg => {
                this.debug("console.log() from page " + this.id + " " + msg.text())
            })

Post by klodoma »

I'll give it a try. Thanks!

Post by klodoma »

If I run it with puppeteer then it seems to work. Never tried it with puppeteer.

Now webdriver vs puppeteer, would you recommend using puppeteer over webdriver?
root@60653ef88db2:/srv/tools/siesta-5.3.2-trial/bin# ./puppeteer 127.0.0.1:88/senchaws/packages/local/ipdu/tests/indexr-no-ui.html --browsesable-gpu --browser-arg no-sandbox
Screenshot_42.png
Screenshot_42.png (92.78 KiB) Viewed 4975 times

Post by nickolay »

This is weird again. Changing launcher should not affect test suite results generally, especially in regard of 404 errors..

Puppeteer launcher is basically same thing as WebDriver + headless Chrome. Using it is fine. It can be a bit faster also.

There are very subtle differences for puppeteer though, for example, afaik, it uses on-demand scroll bars (Mac style).

Post by klodoma »

Ok, I get the feeling it has something todo with the chrome installation that webdriver is using.

I just gave it a shot with firefox and ... it works :)
root@60653ef88db2:/srv/tools/siesta-5.3.2-trial/bin# ./webdriver 127.0.0.1:88/senchaws/packages/local/ipdu/tests/indexr-no-ui.html --headless  --browser=firefox
Screenshot_43.png
Screenshot_43.png (46.94 KiB) Viewed 4974 times

Post by klodoma »

My conclusion is that the issue is related to the webdriver, chrome version or something related to them. I've tried different options to run this, same result. Webdriver with chrome is failing in the docker container.

Post by nickolay »

Ok, good to know. And Puppeteer works fine?

Post Reply