5 ms·

> Their tests are reliable and fast, but they tend to “lock in” implementation, making refactoring difficult Try and make a refactoring for something that has

> Their tests are reliable and fast, but they tend to “lock in” implementation, making refactoring difficult Try and make a refactoring for something that has no unit tests, or upgrade a db for tests that directly validate the values in the db. I'm not sure I get where that claim that mocks lock-in implementation is coming from, if anything they make it less locked in.

Ygg2 4y ago
I think the big issue is. Are you writing a lib or an app? In library you don't need to mock. Library is supposed to be agnostic. In app there are many layers. You kinda need to mock them all, otherwise your app can't be tested. And then you have the problem that minor changes turn your tests red. So mocking is most useful in the place it has almost no impact. https://youtu.be/VDfX44fZoMc https://youtu.be/VDfX44fZoMc
- Ygg2 4y ago
  Clarification of link: one solutions to unit tests is to write even more unit test, with some contract tests, etc. Another approach is to treat integration test as a unit test.
deleted 4y ago
[deleted]
elboru 4y ago
I think one of the biggest issues is the definitions we use. Some developers would define mock in the wide sense, as any kind of double to replace a dependency. Other developers have a narrower definition, as doubles that verify interactions with the dependency (interaction testing https://testing.googleblog.com/2013/03/testing-on-toilet-testing-state-vs.html https://testing.googleblog.com/2013/03/testing-on-toilet-tes...). In this case, the author mentions mocks and spies, therefore he's referring to "interaction testing". In other words, tests that verify that the dependency was called in the "right" way. If you own those dependencies, and later you refactor them you'll also need to refactor any test that used "interaction testing". Refactoring becomes a tedious and sometimes difficult task. If by mock, you simply mean code (written by you or by a "Mock" library) that replaces a dependency to get the right data inside the SUT for the test, but that it's not attached to the dependency implementation, then most of the issues are gone.

Ygg2 4y ago

I think the big issue is. Are you writing a lib or an app? In library you don't need to mock. Library is supposed to be agnostic. In app there are many layers. You kinda need to mock them all, otherwise your app can't be tested. And then you have the problem that minor changes turn your tests red. So mocking is most useful in the place it has almost no impact. https://youtu.be/VDfX44fZoMc https://youtu.be/VDfX44fZoMc

Ygg2 4y ago
Clarification of link: one solutions to unit tests is to write even more unit test, with some contract tests, etc. Another approach is to treat integration test as a unit test.

deleted 4y ago

[deleted]

elboru 4y ago

I think one of the biggest issues is the definitions we use. Some developers would define mock in the wide sense, as any kind of double to replace a dependency. Other developers have a narrower definition, as doubles that verify interactions with the dependency (interaction testing https://testing.googleblog.com/2013/03/testing-on-toilet-testing-state-vs.html https://testing.googleblog.com/2013/03/testing-on-toilet-tes...). In this case, the author mentions mocks and spies, therefore he's referring to "interaction testing". In other words, tests that verify that the dependency was called in the "right" way. If you own those dependencies, and later you refactor them you'll also need to refactor any test that used "interaction testing". Refactoring becomes a tedious and sometimes difficult task. If by mock, you simply mean code (written by you or by a "Mock" library) that replaces a dependency to get the right data inside the SUT for the test, but that it's not attached to the dependency implementation, then most of the issues are gone.