I'm new to TestCafe. I have a requirement to execute the TestCafe automated tests on Internet Explorer(IE) browser.
I'm using TestCafe Studio to record the tests and the TestCafe docker container will be used to run the tests within the pipeline. Since the docker container doesn't support test execution with IE browser. I tried out the "remote" option and got a remote connection URL generated.
Which I need to copy and paste in to the remote IE browser where I want to execute the tests. Is there any way that I can automatically triggers test execution with the generated remote connection URL without manually copy and paste the URL?
docker run --add-host=my.host:127.0.0.1 -p 1337:1337 -p 1338:1338 -v /Users/Documents/GIT/Projects/e2e_tests:/tests -it testcafe/testcafe --hostname my.host remote -q --skip-js-errors --assertion-timeout 20000 --selector-timeout 20000 '/tests/Tests/**/*.testcafe'
You can write a script (using Batch/PowerShell, etc.) that starts the TestCafe container with a remote mode enabled and then navigates Internet Explorer to the connection URL, which is http://${HOSTNAME}:${PORT1}/browser/connect (where HOSTNAME and PORT1 are variables that were used to launch TestCafe). Check out this answer. It contains a bash script that implements this approach for the automation of test launch in the Safari browser using the remote mode.
Also note that TestCafe allows you to use browsers from cloud testing services. BrowserStack and Sauce Labs services provide Internet Explorer among many other browsers, so I assume it would be simpler to make your tests run in IE.
Related
I connect remote windows server in Jenkins by node&slave concept and I create a "freestyle" job and run batch command in Jenkins in that command I wrote selenium scripts. the job was working fine.
When a test fails it takes a screenshot of the browser window. Unfortunately, the browser is always a fairly low resolution: 1024 x 656.
If I run the tests manually within the VM (logging in and running them outside of Jenkins) then they're run at the desktop resolution of the login.
So, my question: how can I set the screen resolution that is used when the tests are run by the Jenkins Service? Is this possible?
Im running chrome headless through chromedriver and selenium via python.
I've run into the following issue both on Mac and Linux.
Im starting chrome as follows:
if self.headless:
options.headless = True
options.add_argument("--headless")
if self.debug_port:
logging.info(f"Setting up remote debugging on port {self.debug_port}")
options.add_argument(f"--remote-debugging-port={self.debug_port}")
options.add_argument(f"--remote-debugging-address=0.0.0.0")
If I connect to http://localhost:9222 from another headed instance of chrome I can see the list of sessions and connect to it seamlessly. At which point i have a window opened up with a screencast of the remote session and the dev console.
Here's that successful example:
When I connect to http://192.168.1.194:9222 I get the list of sessions just fine and upon selecting one the dev console opens but it doesn't start the websocket connection to ws://192.168.1.194 so the screencast and remote debugging capabilities are not available.
Here's that failed example:
I've captured har files and uploaded them here if you want to take a look
Using the following steps I was able to debug remotely. However the screencast functionality did not work. Ultimately that's what I needed so this is only a 50% solution in my case.
So, as noted above in the comments, what's blocking remote debugging from working is that the chrome debugger links out to https://chrome-devtools-frontend.appspot.com/..... and passes a value of ws://192.168.1.194 for the websocket parameter. Any browser will inherently block this, based on it being mixed content - i.e: https + ws
What's needed here is to run the chrome dev tools frontend on a http server
and direct your chrome instance to that server instead of the appspot instance.
Solution Steps
1 Install depot_tools (pre-requisite for building)
https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html#_setting_up
2 Checkout the devtools-frontend repo
https://github.com/ChromeDevTools/devtools-frontend/blob/master/docs/workflows.md#checking-out-source
3 Build chrome devtools frontend
https://github.com/ChromeDevTools/devtools-frontend/blob/master/docs/workflows.md#build
4 Start the devtools-frontend http server
https://github.com/ChromeDevTools/devtools-frontend/blob/master/docs/workflows.md#running-in-hosted-mode
5 Run 2 instances of chrome and use one to debug the other
5.1 Start first instance of chrome headless
...with remote debugging enabled. See the python way in the question above or do it from the command line with the same arguments
5.2 Start a second instance of chrome
...using a different user data dir --user-data-dir=<some-path>
5.3 Navigate to http://192.168.1.194:9222
Use whatever the IP address of the first chrome instance is and the port that you chose.
5.4 Create a link to the local dev server
The 2nd instance of chrome will now be showing you links to debug each of the open tabs of the 1st instance. However the links will still to go https://chrome-devtools-frontend.appspot.com/..... You'll need to copy n paste the link you want and replace the hostname with the hostname of the devtools frontend that you started in step 4
Walla!!
If you figure out how to get the screencast working please comment below! 🙏
N.B:
I also tried using the npm run server command in the devtools frontend but for some reason that server didn't work at all ¯\_(ツ)_/¯
First and foremost, the "remote" function of Testcafe is easily one of the best and most portable browser testing implementations I have ever come across; excellent work to the team developing it.
When I run npx testcafe remote ./tests --ports 5567,5568
The runner will notify me that it's listening on http://localhost:5567/browser/connect. Fantastic, now I want to launch my browser and navigate to this URL.
My browser might be a headless browser inside a docker container, or it could be a remote server running MacOS - regardless of its location, the remote needs to be issued commands after the test runner is ready and accepting connections.
Is there an endpoint like /ping or something that I can send a request to that will notify me of the test runner's active status?
npx concurrently \
"npx wait-on http://localhost:5567/ping && remote-browser-util IOS_SAFARI http://localhost:5567/browser/connect" \
"npx testcafe remote ./tests --ports 5567,5568"
TestCafe is ready to accept browser connections as soon as specified ports are occupied. So you can use wait-on tcp:5567 to delay the start of your browser.
When I run my selenium scripts through Jenkins, browser was not instantiated in Jenkins server but my Jenkins build was pass. Build should be failed. can you please help me to provide solution on this ?
It seems you are using windows, "you need to allow Jenkins service to interact with desktop"
follow below step in order to enable Jenkins service to interact with desktop.
1- open run and search for "services.msc"
2- Scroll down to the Jenkins service and right-click, select Properties.
3- Now click on Log on Tab and you will see "Allow service to interact with desktop" check this checkbox and you are done.
We have a CI setup using bamboo where one job was to run our automation, it checks out our Automation Solution from a repository, and run it using NUnit runner where it contains tests using selenium webdriver and some unit tests. It runs unit tests(not using webdriver commands) just fine, but not the webdriver tests.
We are sure that the solution is being checkout correctly because we can run the test using the command line referencing the created local repository, including tests that uses webdriver using the command below:
C:\pathToNUnitConsole\nunit-console C:\pathToCreatedLocalRepositoryInTheServer\NUnitTest.dll -include=FirefoxBrowserTest
We can see that the bamboo job never launched a browser, and we are getting test failure for not seeing browser elements. Also, we are getting error as we see in the logs:
10-Apr-2015 13:19:49 http://10.215.12.28:15871/cgi-bin/blockpage.cgi?ws-session=587410860
10-Apr-2015 13:20:42 JavaScript error: resource://gre/modules/CertUtils.jsm, line 168: NS_ERROR_ABORT: Certificate issuer is not built-in.
I don't know if this is your problem, but it sounds very similar to an issue I had trying to get NUnit runner to run tests built in SpecsFor.MVC, which is a wrapper that deals with instantiating an IIS Express instance, deploying a target web application to known location, then using Selenium/Chrome Driver to run the tests against the web app.
The problem I had was trying to run the Bamboo remote agent as a windows service. The Local Service account was not able to access the interactive desktop. Also, changing the service to run as a specific user account still failed, as the service was not allowed access to the user's isolated Session0.
I could login as that test user and run the test from the command line no trouble, but I couldn't get it to run when initiated by the remote agent windows service.
I eventually fixed it by using AlwaysUp (not a plug. I'm sure other similar solutions are available). This allowed me to set the machine running the tests to always log in as the test user on startup, would automatically restart the bamboo remote agent if it was closed for some reason and most importantly, to give the service access to the user's isolated session0.
Hope that might give you a few clues...