Hi Jonny,
Thanks for looking at this.
/"First, would it make sense for this to simply be a submodule of
the Geb repository?"/
Yes, I was thinking it could be released as a library like geb-spock,
geb-junit5, etc.
/"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."/
Definitely something to explore.
On the example application, Yes it was just meant to be a happy-path
test example but you have a good point about the separate JVM.
I'm working on implementing that now.
I like the idea of having the example projects in the repo for Geb. I
think it makes it easier to follow the current project version than
having something separate go update.
/"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."/
/
/
I was originally thinking of under modules since it's a library, but
being under integration now makes sense to me.
/"Eliminate the need for any redundant code within the codebase
(like GrailsContainerGebExtension, above); look at modifying,
composing, or subclassing existing extension points if necessary.//"/
Once we get this started, the Grails team may have some thoughts as well
as they did what they had to do from the outside.
/"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."/
I have been working on bringing some settings from GebConfig into
WebDriverContainerHolder as I've needed them where Grails did not, or in
some cases they have started to move in that direction also instead of
system properties and I've followed that lead. More can be done here.
Maybe the next step could be create a geb-testcontainers branch to work
in and I can start getting the code pushed in and a build working and go
from there?
Best regards,
Carl
On 12/30/25 11:15 AM, Jonny wrote:
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
