Re: [GEB] adding a Testcontainers module to Geb

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
>