Re: [GEB] adding a Testcontainers module to Geb

I've created a task/geb-testcontainers branch and I'll start there.

I plan on adding "geb-testcontainers" under "integration" and start from 
there unless there are concerns with the module name or location.

Thanks for the feedback!

Best regards,

Carl

On 1/5/26 12:27 PM, Jonny wrote:
> 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
>