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
> >
>
