tags |
---|
testing, mocks |
- https://www.jamesshore.com/Blog/Lunch-and-Learn/Testing-Without-Mocks.html
- https://www.youtube.com/watch?v=jwbKSiqG0DI
Although mocks (and spies) are useful for testing interactions and isolating code, that isolation comes at a cost. Mock-based tests are solitary tests: mocks can only check if dependencies' methods are being called. They can't check if they're being called correctly.
Mock-based tests will check that A
works correctly, and that it's using B
, but it will not check that B
behaves the way A
expects, it won't check that A
is using B
correctly => GAPS!
So you'll end up with gaps, and, as a result, mock-based tests must be supplemented with integration tests, and these tests are slow and expensive.
Wouldn’t it be nice if we could write unit tests that didn’t need additional integration testing?
how to fill the gap between app.js
and command_line.js
?
The solution use two tecniques:
In a Overlapping Sociable Tests the deps of an object are not behaviours to be tested but implementations to wrap. They are "overlapping" because they are testing production paths on the real collaborator, instead of using test doubles to cut off the downstream dependencies.
Nullable Infrastructure Wrappers
- are wrappers of infrastructure inside our collaborator
- is real production code that can be disabled
- identical semantic of real production code
- the only difference is the part where we talk to the outside world (which is turned off)
- tracks state as needed (??)
- implemented with embedded stubs to turn off the real talk to the outside world while be as real as possible
- with embedded stubs you only stub third-party code (which is the opposite of mock objects, where you never stub third-party
)
- with embedded stubs you only stub third-party code (which is the opposite of mock objects, where you never stub third-party
Nullable infrastructure bring ugliness, as much as using mocks... which ugliness do you prefer? => TRADE-OFFS and context