replaced mock with fake/stub for SendMoneyServiceTest#31
Open
gerlacdt wants to merge 2 commits intothombergs:masterfrom
Open
replaced mock with fake/stub for SendMoneyServiceTest#31gerlacdt wants to merge 2 commits intothombergs:masterfrom
gerlacdt wants to merge 2 commits intothombergs:masterfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi,
I read your book Get Your Hands Dirty on Clean Architecture and I liked it very much. I almost agree with everything on it.
But one thing is bothering me: it's the usage of mocks in tests. From experience, I know, tests with mocks are brittle. Further the test code is deluged with mock-statements and harder to comprehend.
The main purpose of hexagonal or clean architecture is loose coupling. I wonder why we toss the good intention overboard for our test code?!? With mocks, we expose the internals of our implementation classes and therefore we loose the ability to refactor the inner details of our service classes. Whereby refactoring is a major reason, why we write tests after all.
This PR offers a small taste, how tests could look like with fakes/stubs instead of mocks. Regarding the tests, I tried to assert one behaviour per test in order to assure a test breaks because of a single reason, this narrows down the potential problem area.
Mocks could be useful in rare cases though. The classic example is: testing a cache. With state verification, you can only check the returned value, but one would not know if the value came from the database or from the cache. With mocks, one can verify that the first call returned from the database and the second call returned from the cache.
I hope the PR is a bit helpful :)