Tasty mocking framework for unit tests in Java

Mockito

Build Status Coverage Status MIT License

Latest 2.x on bintray Latest 2.x on Maven Central

Current version is 2

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

See the release notes page and latest documentation (docs in javadoc.io are available 24h after release).

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

Project status updates

Updates are announced via Twitter Twitter logo and mailing list Google Groups.

After releasing Mockito 2 (see what’s new) the team will continue to improve version 2.x for a short time, then focus on Mockito 3. Please provide your feedback and suggestions for the scope of Mockito 3.x using the above two channels and GitHub issue tracker. Mockito 3.x will target Java 8.

Contributions welcome

Fancy getting world-wide visibility and building up an eternal fame of an OSS contributor?

Fork me on GitHub

Why drink it?

Mockito is a mocking framework that tastes really good. It lets you write beautiful tests with a clean & simple API. Mockito doesn’t give you hangover because the tests are very readable and they produce clean verification errors. Read more about features & motivations.

  • Massive StackOverflow community voted Mockito the best mocking framework for java. Even though StackOverflow shuns questions that likely raise emotional debates the fact is Mockito has the most votes. You can add your vote, too!

  • Top 10 Java library across all libraries, not only the testing tools. In late 2013 there was an analysis made of 30.000 GitHub projects. Although Mockito reached number 9 in the main report, mockito-core and mockito-all are the same tool and therefore the factual position of Mockito is number 4, surpassing famous tools like Guava or Spring. Treat this study as an indicator of a big impact that Mockito makes every day on unit tests written in Java.

  • Dan North, the originator of Behavior-Driven Development wrote this back in 2008:

    “We decided during the main conference that we should use JUnit 4 and Mockito because we think they are the future of TDD and mocking in Java”

    Given the current popularity of Mockito, Dan was spot on with his prediction.

Use your own judgement in choosing a testing framework. The Mockito team always respects your choice. Keep writing great tests every day!

How do I drink it?

Recommended way of getting Mockito is declaring a dependency on “mockito-core” library using your favorite build system. With Gradle one can do:

repositories { jcenter() }
dependencies { testCompile "org.mockito:mockito-core:2.+" }

Maven users can declare a dependency on mockito-core. Mockito is automatically published to Bintray’s jcenter and synced to the Maven Central Repository.

Legacy builds with manual dependency management can use 1.* “mockito-all” distribution. It can be downloaded from Mockito’s Bintray repository or Bintray’s jcenter. “mockito-all” distribution has been discontinued in Mockito 2.*.

now you can verify interactions

import static org.mockito.Mockito.*;

// mock creation
List mockedList = mock(List.class);

// using mock object - it does not throw any "unexpected interaction" exception
mockedList.add("one");
mockedList.clear();

// selective, explicit, highly readable verification
verify(mockedList).add("one");
verify(mockedList).clear();

and stub method calls

// you can mock concrete classes, not only interfaces
LinkedList mockedList = mock(LinkedList.class);

// stubbing appears before the actual execution
when(mockedList.get(0)).thenReturn("first");

// the following prints "first"
System.out.println(mockedList.get(0));

// the following prints "null" because get(999) was not stubbed
System.out.println(mockedList.get(999));

More info

Main reference documentation features:

  • mock()/@Mock: create mock
  • spy()/@Spy: partial mocking, real methods are invoked but still can be verified and stubbed
  • @InjectMocks: automatically inject mocks/spies fields annotated with @Spy or @Mock
  • verify(): to check methods were called with given arguments
    • can use flexible argument matching, for example any expression via the any()
    • or capture what arguments where called using @Captor instead
  • Try Behavior-Driven development syntax with BDDMockito
  • Use Mockito on Android, thanks to the Google guys working on dexmaker

Remember

  • Do not mock types you don’t own
  • Don’t mock value objects
  • Don’t mock everything
  • Show love with your tests!

Click here for more documentation and examples. All documentation lives in javadocs so you don’t need to visit that page too often. There is also a RefCard.

If you have suggestions, find documentation unclear, or find a bug, write to our mailing list. You can report feature requests and bugs in GitHub.

Mockito is served to you by Szczepan Faber and friends. First engineers who were using Mockito in production were developers of the Guardian project in London in early 2008. Szczepan was lucky to be a part of the ThoughtWorks team assigned to the challenging and exciting Guardian project. Here is how he explained why we needed another mocking framework?

Hats down before EasyMock folks for their ideas on beautiful and refactoring-friendly mocking API. First hacks on Mockito were done on top of the EasyMock code.

Currently Mockito is maintained by Szczepan Faber, Brice Dutheil, Rafael Winterhalter, Tim van der Lippe, Marcin Grzejszczak, Marcin Zajączkowski and a small army of contributors. Friends who contributed to Mockito (apologize if I missed somebody): Pascal Schumacher, Christian Schwartz, Igor Czechowski, Patric Fornasier, Jim Barritt, Felix Leipold, Liz Keogh, Dan North, Bartosz Bańkowski, David Wallace.

Travis CI and Bintray are used to facilitate continuous delivery. Both tools are great. Thank you Travis, thank you Bintray!

  • Thanks to Éric Lefevre-Ardant for his long running and continuous support on the mailing-list
  • Thanks to Erik Ramfelt, and Steve Christou for the Jenkins server that was used originally for CI.
  • Thanks to Erik Brakkee who originally helped with maven central syncing.
  • Thanks to Igor Czechowski for dealing with maven central and for the name “Mockito”!
  • Thanks to Karol Poźniak for the original colorful logo, Darek Chrzan for the second one, and Évy Dutheil for the third :)

Training by core engineers

Mockito core engineers, experts in the field of software quality can help you with:

  • getting your team up to speed with test automation with mock objects
  • enabling and sustaining test driven development in its best form: BDD
  • achieving maintainable, high quality tests that unlock continuous delivery
  • securing production code quality and minimizing defects through rigorous test automation

Get in touch at info@mockito.org

Mockito is open source — Want to contribute? — Issue tracker — Mailing list — Training offering