matrei opened a new issue, #16381:
URL: https://github.com/apache/grails-core/issues/16381

   **Environment**
   - Grails 8.0.0-M6 (generated with Grails Forge, `applicationType: web`, 
feature `geb-with-webdriver-binaries`)
   - Gradle 9.6.0 (wrapper), Java 21.0.12 (BellSoft), Linux, Firefox 156
   - Also affects 7.0.x (same template and plugin version)
   
   **Steps to reproduce**
   1. Generate a web app with the `geb-with-webdriver-binaries` feature.
   2. Run `./gradlew integrationTest`.
   
   **Expected:** the build configures and the generated functional test runs.
   **Actual:** the build fails while evaluating `build.gradle` (issue 1). After 
fixing that, the webdriver-binaries setup still has no effect (issue 2), and 
the `geb.env` environments suggested in `GebConfig.groovy` are ignored (issue 
3).
   
   ---
   
   ## 1. `webdriverBinaries` DSL is incompatible with webdriver-binaries plugin 
4.x
   
   The generated build applies `id "org.ysb33r.webdriver-binaries" version 
"4.0.0"` but configures it with the old String syntax:
   
   ```groovy
   webdriverBinaries {
       chromedriver '122.0.6260.0'
       geckodriver '0.33.0'
       edgedriver '110.0.1587.57'
   }
   ```
   
   ```
   Build file 'build.gradle' line: 85
   > Could not find method chromedriver() for arguments [122.0.6260.0] on 
extension 'webdriverBinaries' of type 
org.ysb33r.gradle.webdriver.WebDriverBinariesPluginExtension.
   ```
   
   In 4.x, `chromedriver`/`geckodriver`/`edgedriver` only accept an 
`Action`/`Closure` that configures `version`, `versionRegexp` or 
`useLatestVersion()`. The working syntax is `chromedriver { version = 
'122.0.6260.0' }`. The same applies to 4.0.1.
   
   ## 2. The webdriver-binaries plugin isn't connected to any test task, and 
the pinned driver versions are outdated
   
   webdriver-binaries 4.x no longer configures `Test` tasks automatically. The 
build has to call `webdriverBinaries.configureTestTask(...)` or 
`configureTestTasks(...)`, and the generated build doesn't. As a result, no 
`webdriver.*.driver` system properties reach the test JVM, and the 
`webdriverBinaries` block has no effect. A local-browser `GebSpec` only passes 
because Selenium Manager (built into Selenium 4.6+) finds a matching driver on 
its own, geckodriver 0.37.1 in this case.
   
   The pinned versions are also outdated: chromedriver 122 (early 2024), 
geckodriver 0.33.0 (2023), edgedriver 110 (early 2023). ChromeDriver and 
EdgeDriver must match the browser's major version, so these pins would fail 
against current browsers if they were used.
   
   Suggestion: either connect the plugin 
(`configureTestTasks(tasks.withType(Test))`, preferably with 
`useLatestVersion()` instead of fixed pins), or drop the plugin from this 
feature and rely on Selenium Manager.
   
   ## 3. `-Dgeb.env=...` is not passed to the test JVM
   
   The generated `GebConfig.groovy` says:
   
   ```groovy
   // run via “./gradlew -Dgeb.env=firefoxHeadless iT”
   ```
   
   But Gradle applies `-D` to its own JVM, not the forked test JVM, and the 
generated build doesn't pass `geb.env` along. The environment is silently 
ignored, and tests run with the default visible browser. Suggested addition to 
the generated build:
   
   ```groovy
   tasks.withType(Test).configureEach {
       useJUnitPlatform()
       def gebEnv = providers.systemProperty('geb.env')
       if (gebEnv.present) {
           systemProperty 'geb.env', gebEnv.get()
       }
   }
   ```
   
   With this in place, `-Dgeb.env=firefoxHeadless` works: Firefox starts with 
`-headless` and the test passes.
   
   ## Question: should `geb-with-webdriver-binaries` and 
`geb-with-testcontainers` both be selected?
   
   The generated `grails-forge-cli.yml` lists both features, and the generated 
spec extends `grails.plugin.geb.ContainerGebSpec` (Testcontainers). If 
webdriver-binaries is meant for running tests against a local browser, should 
selecting it replace `geb-with-testcontainers` and generate a 
`geb.spock.GebSpec` instead?
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to