4 ms·
Mocks (and fakes) have their place; verifying the behavior in exceptional circumstances in a deterministic way (avoiding flaky tests) and unit-testing code exha
by benlivengood 5y ago
Mocks (and fakes) have their place; verifying the behavior in exceptional circumstances in a deterministic way (avoiding flaky tests) and unit-testing code exhaustively that would otherwise be too slow if written as full integration tests. Filesystem, network, and database dependencies are good places to mock/fake because errors are rare (and would be flaky) in integration tests and maintaining backend state for a lot of unit tests can slow the development cycle.
Yes, keeping mocks in sync with reality is hard but it should be up to the library owner to maintain either a good set of mocks or provide a fast enough library that integration tests are the better choice. This works in a company with uniform testing goals as a core value, not so we'll when dependencies and users have different testing philosophies.
- mikepurvis 5y agoI think the distinction I'm seeing here is that a mock is a pretend implementation of whatever the interface is, either at a code or service level, whereas as a fake is that actual service in whatever its minimally-viable state is. So like— not mocking out the database interface with cooked responses, but instead using an actual instance of the database.