Most popular mocking framework for Java

Current version is 2.x

Still on Mockito 1.x? See what's new in Mockito 2!

Mockito continuously delivers improvements using Shipkit library ( http://shipkit.org). See the latest release notes and latest documentation. Docs in javadoc.io are available 24h after release. Read also about semantic versioning in Mockito.

Older 1.x releases are available in Central Repository , Bintray and javadoc.io (documentation).

More information

All you want to know about Mockito is hosted at The Mockito Site which is Open Source and likes pull requests, too.

Want to contribute? Take a look at the Contributing Guide.

Enjoy Mockito!

Need help?

• Search / Ask question on stackoverflow
• Go to the mockito mailing-list (moderated)
• Open a ticket in GitHub issue tracker

How to develop Mockito?

To build locally:

 ./gradlew build 

To develop in IntelliJ IDEA you can use built-in Gradle import wizard in IDEA. Alternatively generate the importable IDEA metadata files using:

 ./gradlew idea 

Then, open the generated *.ipr file in IDEA.

How to release new version?

Mockito implements Continuous Delivery model. Every change on main branch (for example merging a pull request) triggers a release build on Travis CI. The build publishes new version if specific criteria are met: all tests green, no 'ci skip release' used in commit message, see the build log for more information. Every new version is published to "mockito/maven" Bintray repository. New versions that Mockito team deems "notable" are additionally published to Maven Central and JCenter. We used to publish every version to Maven Central but we changed this strategy based on feedback from the community ( #911).

• Q: What's new in Mockito release model?

  A: In Q2 2017 we implemented Mockito Continuous Delivery Pipeline 2.0. Not every every version is published to Maven Central.

• Q: How to publish to Maven Central?

  A: Include "[ci maven-central-release]" in the merge commit when merging the PR. Caveat: if the PR does not change the binaries / javadoc in any way, the release will be skipped. To avoid this problem, make a whitespace change in javadoc Javadoc for some public type. We will address this caveat, see issue #353 in Shipkit. Hint: To signify a new feature consider updating version to next minor/major, like: "2.8.0", "2.9.0", "3.0.0".

• Q: How to promote already released version to a notable version?

  A: It isn't automated at the moment. What's the use case?