Thanks for that context, James. That's all helpful! I had thought that
testcontainers had some Windows support
(https://java.testcontainers.org/supported_docker_environment/windows/),
though there are limitations that might prevent it from working for
our case.
I agree that the best path forward would be for Carl to start a branch
working on rolling it into the repository, as outlined above. Carl, if
there's anything I can do to make one of my suggestions clearer or
otherwise help unstick something, please let me know.
Best,
Jonny
On Wed, Dec 31, 2025 at 10:56 PM James Daugherty
<[email protected]> wrote:
@Carl, I want to say thank you for doing this initial work. I'm
thrilled you've followed up on our initial discussions. We originally
set out to make the Geb configuration easier and moving this
functionality into Geb itself is a worthwhile effort - especially if
there's support by the project. I'd rather the Grails plugin simply
be a wrapper around upstream functionality if at all possible and it
seems like Jonny likes the idea too so it's worth pursuing.
@Jonny Concerning the GrailsContainerGebExtension, I copied the Geb
extension code when I created the Grails spock extension since there
wasn't an easy way to invoke that code and I needed to perform
additional steps for the container setup. Making it more extensible
is definitely the right solution here. There's no reason to
duplicate.
Concerning the property configuration; we tried several approaches.
Initially it was annotation based configuration, then system
properties, and finally we started supporting the GebConfig file
itself. @Mattias & @Jonas substantially evolved my initial work on
using a spock extension. Specifically, Jonas made substantial
improvements to it and will likely have more feedback here. I'm
including them both on this email chain for their thoughts.
Concerning the examples, I'm assuming those examples are effectively
functional/end-to-end tests for Geb. While I'm not a commiter on the
Geb project, I would strongly advise you to place the examples in the
main repository. When we merged the Grails functional tests into the
main repo, it helped accelerate our testing and helped ensure stable
releases. As we have refactored, it's been much easier to make larger
changes.
Concerning using testcontainers, one downside is there isn't really a
windows equivalent. If people are using Geb to drive browsers on
windows that need can't exactly be met. WIth that said, windows
machines can run linux containers, and the assumption is the browser
is similar enough on a different OS that it doesn't matter.
@Jonny for the spock vs testcontainers, the current implementation is
tied to spock. I'm not sure if that factors into a top level or an
integration module - I'm not as familiar with how Geb's project is
structured.
Regards,
James
On Wed, Dec 31, 2025 at 6:43 PM Carl Marcum
<[email protected]> wrote:
>
> 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:
>
> > 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 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, 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:
>
> 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.
> Eliminate the need for any redundant code within the codebase
(like GrailsContainerGebExtension, above); look at modifying,
composing, or subclassing existing extension points if necessary.
> 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
