Re: [GEB] adding a Testcontainers module to Geb

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
>