You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Carl Marcum <ca...@gmail.com> on 2025/10/21 22:48:36 UTC
[GEB] adding a Testcontainers module to Geb
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
Re: [GEB] adding a Testcontainers module to Geb
Posted by Carl Marcum <ca...@gmail.com>.
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
> <jd...@apache.org> 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
> <ca...@gmail.com> 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
> <ca...@gmail.com> 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
>
Re: [GEB] adding a Testcontainers module to Geb
Posted by Jonny <jo...@gmail.com>.
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 <jd...@apache.org>
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 <ca...@gmail.com>
> 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 <ca...@gmail.com>
> 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
>
Re: [GEB] adding a Testcontainers module to Geb
Posted by James Daugherty <jd...@apache.org>.
@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 <ca...@gmail.com> 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 <ca...@gmail.com> 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
Re: [GEB] adding a Testcontainers module to Geb
Posted by Carl Marcum <ca...@gmail.com>.
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 <ca...@gmail.com>
> 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
>
Re: [GEB] adding a Testcontainers module to Geb
Posted by Jonny <jo...@apache.org>.
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 <ca...@gmail.com> 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
>