Top AI Repos — open-source AI, indexed and scored
Top AI Repos tracks AI repositories on GitHub and answers two different questions about each one: is it moving right now, and would you bet a product on it.
Top AI Repos tracks AI repositories on GitHub and answers two different questions about each one: is it moving right now, and would you bet a product on it.
Mockito for Scala language
| Date | Stars |
|---|---|
| 2026-07-24 | 366 |
| 2026-07-25 | 366 |
| 2026-07-28 | 366 |
| 2026-07-30 | 366 |
| 2026-08-06 | 366 |
Today
— stars today
This week
— stars this week
This month
— stars this month
Momentum
35.0
growth rate 0.00%/day
# Mockito Scala
<a href="http://site.mockito.org">
<img src="https://github.com/mockito/mockito/raw/release/2.x/src/javadoc/org/mockito/logo.png"
srcset="https://github.com/mockito/mockito/raw/release/2.x/src/javadoc/org/mockito/[email protected] 2x"
alt="Mockito" />
</a>
The most popular mocking framework for Java, now in Scala!!!
[](https://search.maven.org/search?q=mockito-scala)
[](https://gitter.im/mockito-scala/)
[](https://typelevel.org/cats/)
## Why separate project?
The library has independent developers, release cycle and versioning from core mockito library (<https://github.com/mockito/mockito>). This is intentional because core Mockito developers don't use Scala and cannot confidently review PRs, and set the vision for the Scala library.
## Dependency
* Artifact identifier: "org.mockito:mockito-scala_[scala-version]:[version]"
* Artifact identifier: "org.mockito:mockito-scala-scalatest_[scala-version]:[version]"
* Artifact identifier: "org.mockito:mockito-scala-specs2_[scala-version]:[version]"
* Artifact identifier: "org.mockito:mockito-scala-cats_[scala-version]:[version]"
* Artifact identifier: "org.mockito:mockito-scala-scalaz_[scala-version]:[version]"
* Latest version - see [release notes](/docs/release-notes.md)
* Repositories: [Maven Central](https://search.maven.org/search?q=mockito-scala)
### Please ensure you don't declare `mockito-core` as a dependency. `mockito-scala` will pull the appropriate version automatically
### Note: For more examples and use cases than the ones shown below, please refer to the library's specific tests
- [Cats](/cats/src/test)
- [ScalaTest](/scalatest/src/test)
- [Specs2](/specs2/src/test)
- [Scalaz](/scalaz/src/test)
## Partial unification
If you're in Scala 2.12 you'll probably want to add the compiler flag `-Ypartial-unification`, if you don't you risk some compile errors when trying to stub complex types using the idiomatic syntax
## Notes for 2.1.0
### Scala 3: `mock[T]` wrapper methods must be `inline`
In Scala 3, `mock[T]` uses a compile-time macro to register by-name/vararg parameter metadata
and value-class return types for `T`. This macro only works when `T` is concrete at the call site,
which requires every method in the call chain to be `inline`.
If you wrap `mock[T]` in a helper, declare it `inline`:
```scala
// CORRECT — T is concrete at every call site
inline def lenientMock[T <: AnyRef: ClassTag]: T =
mock[T](Mockito.withSettings().strictness(Strictness.LENIENT))
// WRONG — T is erased; by-name/vararg metadata will NOT be registered
def lenientMock[T <: AnyRef: ClassTag]: T =
mock[T](Mockito.withSettings().strictness(Strictness.LENIENT))
```
Without `inline`, stubs on by-name or vararg methods will silently fail to match at runtime.
## Notes for 2.0.0
We dropped support for Scala 2.11 and Java 8, as Mockito 5 dropped support for Java 8.
Java 11 is now the minimum supported version.
## Notes for 1.13.6
We slightly changed the way one would expect no/no more interactions with a mock object in Expectations DSL.
From now on, `expect (...) to` should only be used on stubbed methods, and can't express expectations about interactions with the mock objects itself.
In order to express expectations on a mock, one would use `expect (...) on` (note the use of `on` vs `to`) where such expectations are supported.
* Instead of `expect no calls to aMock`, use `expect no calls on aMock`.
* Instead of `expect noMore calls to aMock`, use `expect noMore calls on aMock`.
Expectations about no _method_ calls stay the same: `expect no calls to aMock.bar(*)`.
## Notes for 1.13.0
We added a new experimental Expectations DSL for idiomatic syntax. It behaves differently from the original idiomatic verifications:
the user Excerpt of 41,658 characters
Read on GitHubWould you bet a product on this? Bounded 0–100 and slow moving.
matched fp:0076527d7961c81e, topic:testing