jonnybot0 commented on issue #188: URL: https://github.com/apache/groovy-geb/issues/188#issuecomment-2560115874
@paulk-asert - I'm okay with the "it's not headless" assumption, but that begs the question for me of whether the configuration.DriverConfigSpec is even getting run in CI. We have Xvfb running as part of the pipeline in CircleCI, so we should be capable of running in non-headless mode in CI. Not sure we are for this module, though. If you just run `./gradlew :doc:manual-snippets:test --tests "configuration.DriverConfigSpec"`, the build passes but the test doesn't actually run. Thinking through the best way to ensure we get value out of the test, my first thought was to move the test to the `real-browser` submodule. Trouble is, that module is set to use a ChromeDriver. Obviously, these snippets are meant to work whether Firefox is in headless mode or not. Indeed, they do, but your driver config needs to match the environment. `geb.fixture.HeadlessTestSupport` seems like it's partway there, but my hunch is we ought to go a wee bit farther. I noodled around with using asciidoctor stop/start tags to use a different driver configs (see [a35598d](https://github.com/apache/groovy-geb/commit/a35598d2579cc2ae1617b2e02f0881bd2b98473e) on my branch). That makes the spec so difficult to read that I think a better path would be to add a second spec that uses headless mode. That got me thinking: what if we just put the sample code in different files? Depending on the environment, we could load _either_ the headless file _or_ the headed file in the test? The documented examples could read from the normal file. https://github.com/apache/groovy-geb/commit/4075a38e0fdff878268560b626ebb790e3644dda gestures at what I mean, though it doesn't quite pass yet. I just can't shake the feeling that having a test which never actually gets run is risky, particularly for public-facing documentation. I'm going to take a break from this, but if you have any quick pointers that would turn my straw into gold, let me know. :) -- 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]
