Webdriver Options (https://github.com/erdi/webdriver-binaries-gradle-plugin vs https://www.testcontainers.org/modules/webdriver_containers/)

[Mick Hunter]

I first posted in Geb Development and just noticed the dates in that list are quite old (I'm now wondering if that is monitored).

https://groups.google.com/d/msg/geb-dev/zpDS6wTT_pg/-b0Eq-Z5AgAJ

In case this is the correct list to post in, anyone have experience with the question referenced?

[Marcin Erdmann]

Hi Mick,

Geb Development group is still monitored but is quite inactive. That group is supposed to be used for questions about development of Geb itself so would mainly be used by contributors. Your question is more of a usage question so this one is the better list to use in this case.

I have used both webdriver binaries and selenium docker images via testcontainers in the past. Geb's build is using both. I believe there are use cases for both of these options depending on the circumstances and both have their pros and cons. 

Using webdriver binaries will be faster (no overhead to start up a container, the browser in that container and then sending webdriver commands over http to that container) and it allows developers to watch their tests execute when debugging or developing them. On the other hand you cannot use the machine while the tests are running in that setup because you would be stealing focus from the browser leading to test failures. To watch tests executing in a docker container you will need to attach a VNC session or setup recording over VNC (I believe it's something that is part of testcontainers support for selenium) and then watch the recording. On the other hand, it's much easier to fix the version of the browser used for running the tests when using testcontainers (note that auto-update is disabled for browsers in selenium docker images) which means you're not constantly dealing with webdriver/webdriver binary/browser version whack-a-mole.

You can get both approaches working on CI, but for CI services which do not use docker, using webdriver binaries to run the browser locally might be problematic because it's hard to fix the version of the browser and thus keep things working reliably. 

For Geb's CI running in CircleCI (https://github.com/geb/geb/blob/master/.circleci/config.yml), I use a custom docker image (https://github.com/geb/ci-docker-image) which guarantees the version of browsers to be fixed when using webdriver binaries and running the browser locally within the container running the build. 

I also use Selenium's Docker images via testcontainers started from another Docker container in Geb's CI in Circle CI (https://github.com/geb/geb/blob/master/.circleci/config.yml#L49, https://github.com/geb/geb/blob/master/internal/test-support/src/main/groovy/GebConfig.groovy#L29). Note that for that option I'm using images which guarantee fixed browser version, 3.141.59-oxygen (historically fixed versions contained names of chemical elements and now they contain a date, e.g. 3.141.59-20200409), because 3.141.59 gets updated every time a new version of the browser is released which leads to non-reproducible builds and potential breakages. Note that the easiest way to be able to start a docker container from within another container (in this case the container running the build on CI) is to bind dockerd socket when starting up the original container (-v /var/run/docker.sock:/var/run/docker.sock). 

When testing an application running on localhost (this is what Geb's build does, it accesses a test http server running on localhost) a bit of base url management is needed when using a driver running in a separate container. Without going into too much detail, this is where it is handled in Geb's own build: https://github.com/geb/geb/blob/master/internal/test-support/src/main/groovy/GebConfig.groovy#L107.

If you're interested, then there's a Geb workshop authored by Michael Kutz and myself (https://github.com/mkutz/geb-testing-workshop) which is using both approaches (webdriver binaries and a testcontainers managed driver, https://github.com/mkutz/geb-testing-workshop/blob/master/build.gradle, https://github.com/mkutz/geb-testing-workshop/blob/master/src/test/groovy/GebConfig.groovy) in Github Actions (https://github.com/mkutz/geb-testing-workshop/blob/master/.github/workflows/default.yml) to test a an app which consists of a backend and a frontend docker containers (https://github.com/mkutz/geb-testing-workshop/blob/master/docker-compose.yml). Again, a certain amount of dealing with differing base url is in place to get all of the containers and docker host talking to each other depending on which mode the tests are being executed in.

There's also an example Geb project using Gradle as the build tool: https://github.com/geb/geb-example-gradle. It's using the gradle plugin for managing webdriver binaries (https://github.com/geb/geb-example-gradle/blob/master/build.gradle#L39) and to ensure that it also works on Windows, it's set up with additional CI at AppVeyor with fixed browser versions: https://github.com/geb/geb-example-gradle/blob/master/appveyor.yml#L3.

Hopefully this helps even if it does not provide an answer with regards to which of the two options is better.

Marcin

--
You received this message because you are subscribed to the Google Groups "Geb User Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to geb-user+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/29e04a1e-22c1-4686-99c5-9dce3c004850%40googlegroups.com.

[Mike Hunter]

Hi Marcin,

This was very insightful and helpful, thank you!!

Mick

To unsubscribe from this group and stop receiving emails from it, send an email to geb-...@googlegroups.com.