I put together an initial plan for this work here:
https://github.com/jdaugherty/groovy-geb/blob/master/design/geb-playwright-backend-plan.md
AI generated this with some input / research, but obviously there's a lot more
to this. I'm putting this out there in case someone else wants to use it to
get started.
-James
On 2026/07/09 00:03:22 Carl Marcum wrote:
> A while back I was evaluating web test frameworks to use at my employer.
>
> Playwright was a strong contender.
> I ultimately decided on Geb and now using the not yet released Testcontainers
> integration.
> I think this is worth exploring. Especially if it is opt-in.
>
> Just my 2 cents :)
>
> Best regards,
> Carl
>
> On 7/6/26 11:28 PM, James Daugherty wrote:
>
> > It's my understanding that what makes Playwright unique/stable is that it
> > actually receives events - so instead of a polling technique that selenium
> > uses it receives an event when to proceed.
> > (playwright.dev/docs/actionability) It would be nice to have this in Geb
> > since a lot of flaky tests seem to be caused by arbitrary waits.
> >
> > -James
> >
> > On 2026/07/03 23:00:51 James Fredley wrote:
> >> Hey folks,
> >>
> >> I’ve been thinking about ways to bring some of Playwright’s strengths
> >> (BrowserContext isolation, built-in auto-waiting for actionable
> >> elements, strong locator strategies, tracing with
> >> screenshots/DOM/network, video recording, and network interception) into
> >> Geb without forcing everyone to change.
> >>
> >> Since Geb is currently tightly coupled to the Selenium WebDriver model,
> >> a clean path could be an optional geb-direct module under
> >> org.apache.groovy.geb. It would depend on the official Playwright Java
> >> bindings, add a configuration-driven backend (something like driver =
> >> "playwright" or a playwright { browser = "chromium" } block in
> >> GebConfig), and map Geb’s Navigator/content DSL, Browser, $(), waitFor,
> >> Page at checkers, and modules onto Playwright Locators and Contexts.
> >> This would let users opt in for the reliability and debugging wins while
> >> keeping all existing WebDriver/Selenium usage completely untouched as
> >> the default, and advanced features like tracing could hook into Geb’s
> >> existing Reporter system.
> >>
> >> I’d be interested in writing this module if there’s interest from the
> >> community.
> >>
> >> We have a large number of Geb tests in Grails-core and this would help
> >> them run smoothly in CI.
> >>
> >> James Fredley
> >> VP, Apache Grails
> >>
> >> On 2025/12/31 22:17:56 Jonny wrote:
> >> > I've been doing some thinking about Geb and what things I'd like to get
> >> > done in the next year.
> >> >
> >> > This isn't so much announcing a formal roadmap as asking folks for a
> >> > wishlist for Geb. Here are some of the bigger bits that are on my
> >> radar.
> >> > Does anyone else have things on theirs?
> >> >
> >> > *Bugfixes*
> >> >
> >> > *Better thread safety in GebTestManager*
> >> >
> >> >https://github.com/apache/groovy-geb/issues/201 and other issues make me
> >> > think that GebTestManager makes some assumptions, particularly around
> >> how
> >> > JUnit lifecycle methods handle tests, that just don't hold in all
> >> cases. My
> >> > hunch is that there are a lot of bugs embedded in this for parallel
> >> > execution.
> >> >
> >> > Some part of me thinks that the deep answer here is, at least in part,
> >> to
> >> > use newer Java concurrency constructs, such as structured concurrency
> >> ><https://openjdk.org/jeps/453>, but that raises some backward
> >> compatibility
> >> > concerns.
> >> >
> >> > *Projects*
> >> >
> >> > *Testcontainers integration*
> >> > Carl Marcum's work back in October to provide some easy-to-use
> >> integration
> >> > between Geb and Testcontainers seems like a great thing to bring into
> >> the
> >> > Geb project as a first class module. I'd outlined some thoughts on that
> >> ><https://lists.apache.org/thread/k2z0nzdgxrzx2kx429pk6sddtd0r4g5n> in
> >> > another thread, but how do others feel?
> >> >
> >> > *Release automation*
> >> > I let this lapse a bit, but that may be a bit of a saving grace.
> >> Apache's
> >> > Trusted Release Platform
> >> <http://github.com/apache/tooling-trusted-releases>
> >> > seems to be coming along, based on the talk in their Slack channel
> >> ><https://the-asf.slack.com/archives/C049WADAAQG>.
> >> >
> >> > *Bring example projects home*
> >> > We still have a bunch of example projects out in the old Github org. I
> >> > think those are probably best brought in as included builds in the
> >> main Geb
> >> > repo. This is basically what JMH does with their samples project
> >> ><https://github.com/openjdk/jmh/tree/master/jmh-samples>, and I think it
> >> > would be a bit easier to maintain than scattered repositories.
> >> >
> >> > *Geb 9*
> >> > I'd also like to think ahead to breaking/backwards-incompatible changes
> >> > that we'd like to make.
> >> >
> >> > 1. Require Java 25 to build, compile to Java 11 as target. Groovy 5
> >> > requires Java 17 to build, Java 11 as target, so I figured we
> >> should be
> >> > conservative in what we allow, but aggressive in the tooling we use.
> >> > 2. Groovy 5 (and supporting version of Spock, 2.4-groovy-5.0)
> >> > 3. Move from javax -> jakarta
> >> >
> >> > What about BiDi?
> >> > BiDirectional functionality in WebDriver
> >> ><https://www.w3.org/TR/webdriver-bidi/> is something we need to think
> >> about
> >> > how to best expose in Geb. I haven't thought deeply about this, and it
> >> > frankly seems like the biggest blind spot that needs some light shined
> >> on
> >> > it.
> >> >
> >> > What about AI?
> >> > AI-based testing obviously has huge implications for browser testing.
> >> >https://www.browserstack.com/guide/selenium-with-ai is a good read
> >> for some
> >> > near-to-hand reaches that Geb could follow or build on. What other
> >> things
> >> > should we be considering in this vein?
> >> >
> >> > Thanks for any thoughts. Happy New Year!
> >> >
> >> > Best,
> >> >
> >> > Jonny
> >> >
> >>
