Running UI tests in github action fails

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: Add fallback mechanism for WebDriver initialization · christianbaumann/mot-cert-support-app-java@90c5080 · GitHub

[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 -- Downloading
07:29:41.914 [main] INFO -- Extracting driver from compressed file
07:29:42.070 [main] INFO io.github.bonigarcia.wdm.WebDriverManager -- Exporting 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!
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:
Build info: version: '4.14.1', revision: '03f8ede370'
System info: 'Mac OS X', os.arch: 'x86_64', os.version: '12.7.3', java.version: ''
Driver info:
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(

Any advice?


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’.

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));

Great!!! Happy testing.

1 Like

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

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”.


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

1 Like