Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarified strict mocks doc #2105

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Clarified strict mocks doc #2105

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions docs/interaction_based_testing.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -75,10 +75,10 @@ code that expects this type.

.Lenient vs. Strict Mocking Frameworks
****
Like Mockito, we firmly believe that a mocking framework should be lenient by default. This means that unexpected
We firmly believe that a mocking framework should be lenient by default. This means that unexpected
method calls on mock objects (or, in other words, interactions that aren't relevant for the test at hand) are allowed
and answered with a default response. Conversely, mocking frameworks like EasyMock and JMock are strict by default,
and throw an exception for every unexpected method call. While strictness enforces rigor, it can also lead
and answered with a default response. Conversely, other mocking frameworks like EasyMock, JMock and Mockito (starting with Mockito v4)
are strict by default, and throw an exception for every unexpected method call. While strictness enforces rigor, it can also lead
to over-specification, resulting in brittle tests that fail with every other internal code change. Spock's mocking
framework makes it easy to describe only what's relevant about an interaction, avoiding the over-specification trap.
****
Expand Down