Geb: browser automation written in Groovy

Four things it combines, and what each one contributes

Geb is described in one sentence that is worth unpacking, because it defines the whole design. It brings together the power of WebDriver, the elegance of jQuery content selection, the robustness of Page Object modelling and the expressiveness of the Groovy language.

WebDriver is the transport. It is the standard protocol for driving a real browser, which means Geb inherits whatever browser support the driver implementation gives you, and it inherits the requirement that a real browser is present.

jQuery content selection is the content layer. The way tests find things on a page is the part that decides whether a test suite survives a redesign, and borrowing jQuery's selector model means the syntax is already known to anyone who has written front end code, and it is expressive enough to describe a nested structure in a page.

Page Object modelling is the structure layer. Instead of a test script that clicks through a sequence of elements, the page is a class with named methods, and a test becomes a short sequence of those method calls. That is the difference between a test that reads as a specification and one that reads as a script.

Groovy is what makes the four fit together without ceremony. A dynamic language with operator overloading, closures and a terse syntax lets the page object and the selector be written so that a test line looks like the thing a person would say about the software.

An Apache project with the usual governance markers

The repository is hosted under the Apache Software Foundation and carries the standard governance files. There is an.asf.yaml at the top level, a LICENSE file, a NOTICE file, a licenses/ directory and a notices/ directory, and a RELEASING.md alongside a CONTRIBUTING.md. The README itself opens with an SPDX-License-Identifier header for Apache-2.0 and the standard licence text, and the licence is reported as Apache-2.0.

The build and release machinery is visible in the file list too. There is a geb.gradle at the top level, a settings.gradle, a gradle/ directory with the wrapper, gradlew and gradlew.bat for Linux and Windows, a buildSrc/ directory for build logic, a bootstrap/ directory, a gradle.properties, and a build-in-docker.sh script for building inside a container. A.oci/ directory points at an OCI image definition for the build, and a Procfile is present as well.

There is a CircleCI build badge and a Maven Central badge for the artifact org.gebish:geb-core, which tells you the published coordinates and that the release goes out to Maven Central rather than being distributed as a jar from the repository. The contributors badge is for the GitHub contributors graph, and the repository also carries a.tm_properties file, a system.properties file and a.idea/ directory.

The Apache home is at groovy.apache.org/geb, and the README points there for further information rather than trying to be the manual, which is the usual arrangement for a project with a full documentation site.

A multi module layout with examples and integration tests

The top level directory list shows how a library of this size is organised, and the names carry most of the meaning.

There is a module/ directory, which is where the published library code lives, and internal/ for the parts that are not published. There is doc/ for the documentation sources, geb-examples/ for the example applications, and integration/ for the tests that drive a browser. The etc/ directory holds supporting configuration, and bootstrap/ is part of the build bootstrap.

That split between integration/ and module/ is the one worth noting for a contributor. Integration tests need a real browser and are slow and environment dependent, while the unit level tests can run anywhere, and keeping them apart is what lets the fast checks stay fast. A repository that mixes them loses the ability to run a quick check at all.

The examples directory is the part a new user should read first. geb-examples/ is a set of runnable sample applications rather than fragments, and for a library whose main claim is that it reads nicely, seeing what a finished test looks like in a real application is more convincing than any description of the syntax.

The .agents/ directory at the top level is also worth noting. It suggests the project has been set up for coding agents to work in, which is a fairly new convention and one that tells you something about how the maintainers expect contributions to arrive.

Geb is a library, so the surrounding test tooling is your decision

The README is deliberately brief, and the reason is visible in the topic list attached to the repository. The tags include bdd-style-testing-framework, browser-testing, e2e-testing, functional-testing, test-automation and testing-library, alongside selenium, webdriver, devtools, groovy, java and test.

The testing-library tag is the one that sets expectations correctly. Geb is a library that you call from your tests, not a runner that owns your test lifecycle. It does not decide where your test classes live, how failures are reported, whether you run in parallel, or what a build pipeline looks like. You pick a runner, or write plain JUnit tests, and Geb is the layer that drives the browser from inside them.

The same distinction explains why the project describes itself as a browser automation solution rather than a testing framework, even though several of the tags say testing framework. The scope is the browser and the page abstraction, not the whole test process.

For a team choosing a stack, that is the decision to make. If you already have Spock, JUnit or Cucumber in place, Geb slots in beside them and you inherit the reporting and CI you already have. If you are starting from nothing, you are making two choices rather than one, and the Groovy ecosystem has several reasonable answers for the second one.

Where to ask questions, and what the project asks of you

The contributing section of the README is short and has one instruction that says a lot about how the project wants to run.

For issues, you should use the Geb GitHub issue tracker, but with a caveat: avoid submitting usage questions as issues and instead ask on one of the listed forums. There are three, and they are the standard Apache set for a project in this position. The geb-users mailing list on lists.apache.org, the Geb GitHub Discussions forum, and the #geb channel on the Groovy Slack workspace.

The reasoning behind that split is standard in open source and correct here. A usage question in the issue tracker is noise for the maintainers and hard to search later, while a mailing list or a discussion forum is answered in public and stays findable. The rule costs a newcomer a little effort to find the right place, and it is what keeps a tracker usable as a record of actual defects.

For contributions, the README points to CONTRIBUTING.md for the guidelines, and the Apache Software Foundation contribution model applies.

On activity, the last push to the master branch was on 2026-10-14, and the repository has no GitHub releases, which is normal for an Apache project that publishes to Maven Central and to the Apache distribution rather than to GitHub tags. The build badge points at a CircleCI workflow on the master branch, so the continuous integration runs on the default branch.

Editorial conclusion

Adopt Geb when your team already writes Groovy or Java and wants browser tests structured as page objects with readable selectors, because the four ingredients it combines are all things you would otherwise assemble from separate libraries. Do not adopt it if you want a test runner with reporting and a lifecycle, since Geb is a library and the surrounding tooling is a separate decision. Before you commit, read the project site for the current setup, check the Maven Central coordinates for the version you want, and plan for a Gradle based build if you are starting from source, since the repository is a multi module Gradle project with a bootstrap directory and its own build scripts.

Frequently asked questions

Official sources

1. apache/groovy-geb on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README