# EasyMock: a mocking library that has been here since 2001

> EasyMock is a Java library for using mock objects in unit testing, and its repository reads more like a maintenance manual than a README, with three levels of Maven build, a test matrix laid out as directories for Java 8, JUnit 5, TestNG, OSGi and Android, and a deployment procedure that ends in a shell script with a version argument. The newest release is 5.7.0.

**easymock/easymock** — EasyMock, makes mocking easier since 2001

- Repository: https://github.com/easymock/easymock
- Website: http://easymock.org
- Stars: 830 · Forks: 301
- Language: HTML
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/easymock-easymock

## Twenty-five years of mock objects

EasyMock is a Java library that provides an easy way to use Mock Objects in unit testing, and the repository description puts it more plainly: makes mocking easier since 2001.

That date is the headline. A mocking library that has been in continuous use since 2001 has survived several rounds of changes in how Java code is tested, from the era of hand-written stubs through the rise of JUnit 4 and into the current period, and the release history shows it is still moving: 5.5.0 on 2024-11-17, 5.6.0 on 2025-05-18 and 5.7.0 on 2026-08-22, with the last push to the repository on 2026-10-19.

The user documentation and the website are at easymock.org, and the default branch is master.

What the repository is not is a source repository in the usual sense. The top-level listing is dominated by build and release machinery, and the library itself is in one directory, core/, next to a bench/ directory for benchmarks and a long list of test directories. The primary language is recorded as HTML, which is a side effect of the website/ directory rather than a description of the code.

The licence is the one thing this README does not settle. The repository metadata carries no licence classification, and the root has a SECURITY.md and a CONTRIBUTING.md but the licence terms are not in the file list, so anyone planning to depend on the library has to check the project's own terms rather than assume the permissive default that a mature Apache-style library would carry.

## Three build levels, and they are not the same build

The developer section explains that there are three different levels of build, and the distinction is the most useful thing in the document for anyone who wants to contribute.

The first is a build without any active profile, which is a basic compilation of the application:

```
mvn install
```

The second is the full build, which checks code coverage using Jacoco, runs spotbugs and validates that the license headers are correctly set:

```
mvn install -PfullBuild
```

The third is the deploy build, which is the build to launch to deploy to the surefire repository. It assembles the application and adds the gpg checksum, and the command line asks for the passphrase of the gpg private key:

```
mvn install -PdeployBuild
```

The default is therefore the fast one, and the checks are opt-in through a profile. That is a sensible arrangement for a library with a large test matrix, and it does mean that a contributor who only runs mvn install locally is not running the checks that the project considers part of a complete build. The full build has its own script, fullBuild.sh, which is the practical way to run it.

Around those three sit the other Maven invocations the maintainers use, and they are worth scanning because they describe the project's habits. There is the site build, mvn site, which produces spotbugs, checkstyle, jdepends and JavaNCSS reports and needs extra memory, so the README suggests exporting MAVEN_OPTS=-Xmx512m. There is a dependency and plugin version check, mvn versions:display-dependency-updates versions:display-plugin-updates -Pall. There is a source download for the dependencies, mvn dependency:resolve -Dclassifier=sources. There is a licence header refresh, mvn validate license:format -Pall. And there is the Sonar analysis, mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent test sonar:sonar, which is how the coverage data reaches the analysis server in one command.

## The full build is where the project checks itself

Three of the full build's steps have visible artefacts in the repository, and they explain what the project considers a quality bar.

The first is the licence header validation, and the template for it is header.txt at the root. A library that ships under a copyleft or source-available licence, and that checks every file carries the right header in the build, is a project that has been audited at least once by someone who read the headers.

The second is spotbugs, and the exclusion list is findbugs-exclude.xml, which is the historical name for the same tool. An exclusion file that is committed rather than ignored is a record of which warnings the maintainers have decided are acceptable, which is the kind of decision that is easy to make badly and well to make explicitly.

The third is Jacoco for coverage, and the Sonar command shows the coverage report is uploaded as part of the same run rather than being collected separately.

Formatting is handled with the Eclipse formatter, in EasyMock-formatter.xml, which the developer section asks you to import into Eclipse or IntelliJ, along with a matching EasyMock-cleanup.xml, which is the additional clean-up actions that go with that formatter. Having a checked-in formatter and a checked-in clean-up file is what keeps a twenty-five-year-old code base consistent, and it is also why the developer section mentions the IntelliJ and Eclipse setup at all.

The testing side is a set of directories rather than a list, and that is the shape of the compatibility story: the code has to build and pass on several toolchains, so the build is split by environment rather than by feature.

## The test matrix is a directory listing

The top-level listing contains eight test directories, and their names are the project's compatibility statement.

There is test-java8/, which is the oldest supported toolchain, and test-junit5/ for the current one. There is test-testng/ for the other major test framework, and test-nodeps/, which is the interesting one, because it is the variant that runs without the optional dependencies, so it catches a class of bug where a test passes only because something else happened to be on the classpath. There is test-osgi/ for the OSGi runtime, test-android/ for the Android build, test-integration/ for tests that need more than a unit test, and test-deploy/ for the packaging.

A library that still carries a Java 8 test module is telling you it is still used on older toolchains, which is often the case for a library embedded in large enterprise builds. A library that still tests under OSGi is telling you it is still embedded in OSGi containers, which is a smaller and older ecosystem that has not gone away.

The Android module has its own build profile, mvn install -Pandroid, and its own setup instructions in the README: install the Android SDK, configure a real or simulated device, set ANDROID_HOME, and optionally add the platform-tools, tools/bin and emulator directories to the path. There are commands to list the configured devices with emulator -list-avds and to launch one, and the note to activate debug mode on a physical device.

The bench/ directory at the root is the one that is easy to miss. A mocking library that still carries a benchmark module is being measured, and the measurement is there for the maintainers rather than for the users.

## Deployment is a script and a few environment variables

The bundling and deployment section is the longest part of the README and it reads like a runbook, because that is what it is.

The steps are: make sure the poms are on the snapshot of the version you want to deploy, make sure jq is installed, with the reminder that it can be installed with brew, choco, apt-get or yum, add a short note about the features in ReleaseNotes.md and remove the change log part, which will be regenerated automatically, set the gpg_passphrase and github_token environment variables, and then run the deployment script:

```
./deploy-easymock.sh (major|minor|patch)
```

where the parameter tells which version number should be incremented at the end. The instruction during the deployment is to do the different things that are asked, which is a script that prompts.

The recovery instructions are specific and useful. If the build fails before the deployment, run mvn versions:commit -Pall and start over. If something was staged in Maven Central, you can drop the staging repository with mvn nexus-staging:drop.

The versioning itself lives in one file. To update the versions, modify the version in .mvn/maven.config, which is a deliberate choice, because a single source for the version is what lets a script bump a major, minor or patch release without touching twenty poms. The scripts around it are generate-changelog.sh, start-next-version.sh and deploy-website.sh, and the website is deployed from the website/ directory with the same deploy-website.sh script, after making sure that directory is clean.

The deployment section also carries the publishing prerequisites, a login to Sonatype Central and the instructions for creating a signing key, and the site is deployed with the same script once the website directory is clean.

## The developer notes, including the part that did not work

The environment setup section is the most human part of the README, and it includes an admission that most project READMEs would leave out.

The maintainer lists what they use: IntelliJ 2026.1.5 Ultimate, with thanks to JetBrains for the licence, and Maven 3.9.16. And then the alternative, Eclipse, with the note that they tried Eclipse 2026-06 but there was a weird compilation issue with ASM.

That single sentence is a useful signal. A project that has been worked on for a quarter of a century has a deep relationship with the bytecode library it uses, and a compiler issue with ASM is the kind of thing that only a long-lived project meets. It is also a reminder that the Eclipse instructions in the README are second best, and that the IntelliJ path is the tested one.

The rest of the setup is the usual: import the Maven parent project to Eclipse or IntelliJ, install the m2e plugin for Eclipse, and import the formatting file.

The repository layout follows from all of this. Alongside core/ and the test modules, there are the tooling files at the root, the formatter and clean-up files, the findbugs exclusion list, the licence header template, mail.txt, the Maven wrapper with its Windows variant, a.sdkmanrc for the SDK manager, an.editorconfig and.gitattributes, and the.mvn/ directory that holds the version. The scripts at the root are the release and website automation, and the poms and the parent pom.xml are the build itself.

## Conclusion

Adopt EasyMock if you are on the JVM and want a mocking approach where the mock is created from the interface rather than from a recorded script, because that is the design it has had for a quarter of a century and it is still the simplest way to get a test double in a codebase that does not already have a convention. Do not adopt it without checking the licence terms, because the repository metadata carries no licence classification and no licence file appears in the root. Before you pin a version, look at which Java versions the test matrix still covers, and expect the release process itself to be old, since the deployment path assumes a Maven Central account, a GPG key and a script that was written before the current Sonatype publishing flow.

## FAQ

### What is EasyMock and who maintains it?

A Java library that provides an easy way to use mock objects in unit testing, described in the repository as making mocking easier since 2001. The website and user documentation are at easymock.org, the newest release is 5.7.0 from 2026-08-22, and the last push was on 2026-10-19.

### How do I build EasyMock?

There are three levels. mvn install is a basic compilation, mvn install -PfullBuild adds code coverage checks with Jacoco, spotbugs and licence header validation, and mvn install -PdeployBuild assembles the application and signs it with your GPG key. The project also provides fullBuild.sh as a way to run the full build.

### Which environments does EasyMock test against?

The repository splits the tests into directories by environment: test-java8, test-junit5, test-testng, test-nodeps, test-osgi, test-android, test-integration and test-deploy. The android variant has its own Maven profile, mvn install -Pandroid, and needs the Android SDK with ANDROID_HOME configured.

### How is a new EasyMock version released?

The version lives in .mvn/maven.config, and the release is run with ./deploy-easymock.sh and a major, minor or patch argument that says which number to increment. The script needs jq, the gpg_passphrase and github_token environment variables, and a note in ReleaseNotes.md, and a failed staging can be dropped with mvn nexus-staging:drop.

## Sources

- [easymock/easymock on GitHub](https://github.com/easymock/easymock)
- [Issues](https://github.com/easymock/easymock/issues)
- [Project website](http://easymock.org)
- [README](https://github.com/easymock/easymock/blob/master/README.md)
- [Releases](https://github.com/easymock/easymock/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/easymock-easymock