@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
