Running UI tests in github action fails

Discussions
, ,
1

Running UI tests in github action fails

Hi all,

I followed 2.4.2 Adding a Framework to a Pipeline to setup my pipeline on github actions, but the LoginTest is failing: https://github.com/christianbaumann/mot-cert-support-app-java/actions/runs/8016005960/job/21897132340

[INFO] Running com.ministryoftesting.LoginTest
07:29:40.964 [main] INFO io.github.bonigarcia.wdm.WebDriverManager -- Using chromedriver 121.0.6167.184 (resolved driver for Chrome 121)
07:29:41.002 [main] INFO io.github.bonigarcia.wdm.online.Downloader -- Downloading https://storage.googleapis.com/chrome-for-testing-public/121.0.6167.184/mac-x64/chromedriver-mac-x64.zip
07:29:41.914 [main] INFO io.github.bonigarcia.wdm.online.Downloader -- Extracting driver from compressed file chromedriver-mac-x64.zip
07:29:42.070 [main] INFO io.github.bonigarcia.wdm.WebDriverManager -- Exporting webdriver.chrome.driver as /Users/runner/.cache/selenium/chromedriver/mac64/121.0.6167.184/chromedriver
ChromeDriver initialized successfully.
2024-02-23T07:29:43.923Z  INFO 3265 --- [nio-8080-exec-1] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring DispatcherServlet 'dispatcherServlet'
2024-02-23T07:29:43.923Z  INFO 3265 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
2024-02-23T07:29:43.924Z  INFO 3265 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 1 ms
Error:  Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.408 s <<< FAILURE! - in com.ministryoftesting.LoginTest
Error:  testPageUpdatesToProjectPageAfterLogin  Time elapsed: 4.301 s  <<< ERROR!
org.openqa.selenium.NoSuchElementException: 
no such element: Unable to locate element: {"method":"css selector","selector":"*[name='email']"}
  (Session info: chrome-headless-shell=121.0.6167.184)
For documentation on this error, please visit: https://www.selenium.dev/documentation/webdriver/troubleshooting/errors#no-such-element-exception
Build info: version: '4.14.1', revision: '03f8ede370'
System info: os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '12.7.3', java.version: '18.0.2.1'
Driver info: org.openqa.selenium.chrome.ChromeDriver
Command: [220dde387270901eedfde99a8e657bcd, findElement {using=name, value=email}]
Capabilities {acceptInsecureCerts: false, browserName: chrome-headless-shell, browserVersion: 121.0.6167.184, chrome: {chromedriverVersion: 121.0.6167.184 (057a8ae7deb..., userDataDir: /var/folders/h1/8hndypj13ns...}, fedcm:accounts: true, goog:chromeOptions: {debuggerAddress: localhost:49190}, networkConnectionEnabled: false, pageLoadStrategy: normal, platformName: mac, proxy: Proxy(), se:cdp: ws://localhost:49190/devtoo..., se:cdpVersion: 121.0.6167.184, setWindowRect: true, strictFileInteractability: false, timeouts: {implicit: 0, pageLoad: 300000, script: 30000}, unhandledPromptBehavior: dismiss and notify, webauthn:extension:credBlob: true, webauthn:extension:largeBlob: true, webauthn:extension:minPinLength: true, webauthn:extension:prf: true, webauthn:virtualAuthenticators: true}
Session ID: 220dde387270901eedfde99a8e657bcd
	at com.ministryoftesting.LoginTest.testPageUpdatesToProjectPageAfterLogin(LoginTest.java:45)

Any advice?
Thanks!

2 Likes
2

The failure of your LoginTest is due to an instance of “NoSuchElementException” unable to locate the HTML element with the CSS selector with the name ‘email’.

3

Yeah, that’s my understanding as well.

Okay, apparently the UI wasn’t there yet.
Solved by adding a wait before trying to interact with any element:

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(ExpectedConditions.visibilityOfElementLocated(By.name("email")));
2 Likes
4

Great!!! Happy testing.

1 Like
5

How did you arrive at 10 seconds being a good wait interval here? I mean do you not use implicit webdriver waits all of the time, and if not, why?

Do test frameworks (my current tool) that use explicit waits struggle with hard coded wait interval decisions they later have to change?

1 Like
6

To give some context: This is based on the MoT Testautomation Foundations Certificate course.

It was a quick fix, “just” to make the pipeline green, and the easiest, since I just had to copy (and adapt the selector) exactly this line from further down in the test.

The example tests in this chapter of the course are intentionally not “super sophisticated but something that can deliver value rapidly”.
I assume when designing the exercises, @mwinteringham had something in mind like “first make it work, than make it pretty”.

That’s nothing I would do in a “real” test, but for the purpose of getting the pipeline green in the context of an exercise, this was “good enough”.

3 Likes
7

Im glad you noted that an explicit wait is sub-optimal!

1 Like