Hey, Carl! Late in replying, but color me interested! I know testcontainers make browser setup a lot easier and less platform constrained; in particular, it can become easier to use the same configuration on CI and your local environment. I remember James Fredley pointing them out to me during a Geb workshop at Community Over Code earlier this year.
I've been poking around at the implementation. I have a few thoughts. In no particular order: First, would it make sense for this to simply be a submodule of the Geb repository? We already publish integrations (via Gradle plugins) for things like SauceLabs and BrowserStack. I still need to get those working properly (changed maven coordinates has created a bit of faff with the Gradle plugin portal), but it seems like the sort of thing that would be relevant to include "out of the box". Second, these comments on GrailsContainerGebExtension.groovy <https://github.com/cbmarcum/geb-container/blob/main/src/main/groovy/grails/plugin/geb/GrailsContainerGebExtension.groovy#L37> : > ContainerGebSpec cannot be a geb.test.ManagedGebTest ManagedGebTest because it would cause the test > manager to be initialized out of sequence of the container management. > Instead, we initialize the same interceptors as the geb.spock.GebExtension GebExtension does. made me wonder if we need to modify the GebExtension, or create some more extensible base class of it so that geb-containers doesn't have to do so much redundant work. That should, in principle, allow GrailsContainerGebExtension to be simplified. Perhaps it could be removed altogether, if we get the design right. This might also be the kind of thing that would be easier to see (using IDE tooling) and maintain if geb-containers was part of the main Geb repository. Third, I noticed that in your example, the example test <https://github.com/cbmarcum/geb-container-sample/blob/main/app/src/integration-test/groovy/net/codebuilders/GebContainerTestSpec.groovy> runs the app under test inside the same JVM as the Geb test itself. That's not "wrong" or anything, but it did strike me as counter-intuitive, which forced me to think about why. Part of it was just that when I started the test in a debugger and attached a breakpoint to the test, the web application couldn't independently respond to requests. Sometimes that's fine enough, if all you want is the Geb test to run quickly through some "happy path" tests, which is a valid use case. However, if you want to manually poke at your webapp, take thread dumps, or otherwise mess with it while Geb tests are running, you probably want it in its own process. Given that testcontainers are all about isolating and abstracting things away, it seemed sensible that the example would create that kind of separation between the webapp under test and the Geb test itself. Some time ago, I'd talked with Sergio about bringing the various geb-example repositories into the geb repo itself (such as https://github.com/geb/geb-example-maven). Other projects, like jmh and its jmh-samples <https://github.com/openjdk/jmh/tree/master/jmh-samples>, do this and it seems more manageable to me. We could do something like this with your example project, especially if we did publish geb-test-containers as its own module. Would you have any interest in taking this further? Here are some broad brushstrokes ideas of what I'd like to see in a PR into the Geb repository that supported this: 1. I'd be inclined to build it as a new submodule of the `integration` submodule (geb-testcontainers), though maybe it should be a top-level module like geb-spock. Open to persuasion there. 2. Eliminate the need for any redundant code within the codebase (like GrailsContainerGebExtension, above); look at modifying, composing, or subclassing existing extension points if necessary. 3. Consider how we might remove the need for the redundant bits of the grails.geb plugin. For example, I see the properties like grails.geb.atCheckWaiting. I'm pretty sure those just map down to the geb properties of the same name. Is there something we'd need to do to surface them so that folks would be interacting with Geb directly? I'm not looking to break the grails-geb implementation, just considering if there's something we could do at a more fundamental level that would make integration of Geb simpler and easier, and remove the need for the grails project to maintain as much of that code. Maybe the grails.geb properties are a bad example because they don't require more code (I haven't dug into that implementation), but hopefully you get the idea. Thanks again for putting this together. Integrations with popular testing tools like testcontainers is exactly what Geb needs. Best, Jonny On Tue, Oct 21, 2025 at 5:48 PM Carl Marcum <[email protected]> wrote: > Hi All, > > After seeing how Grails was testing with Geb and Testcontainers using > their Grails Geb Plugin [1]. > I had some non-Grails projects to test with Geb so I created a > standalone Geb-Container library [2] based on that plugin. > I modified it some to take out the Grails dependencies and it has worked > out well. > I also setup a sample project for trying it out [3]. > > My thought was that it would make a good addition to Geb as a module and > I wanted to get the your thoughts. > > > [1] https://github.com/apache/grails-core/tree/7.0.x/grails-geb > [2] https://github.com/cbmarcum/geb-container > [3] https://github.com/cbmarcum/geb-container-sample > > Best regards, > Carl >
