Don't Use Mocks
joeblu.com
Don't Use Mocks
1–10 of 85 posts
Re: Don't Use Mocks
#2I feel that if most of your tests relies on mocks it is a symptom of a very side-effected programming style. If you cannot unit test most your business logic then you are probably mixing up your business level code with side-effecting code (like calling APIs or DBs).
Personally I've found it better to split pure business logic and side-effecting logic as close to the edge (API endpoint handler) as possible. Then it is trivial to see where side-effects happen and you get to easily write unit tests for the business logic that matter.
Mocking is mostly always a pain and I would rather not mock at all and do proper end-to-end for integration code if possible.
Re: Don't Use Mocks
#3I feel that if most of your tests relies on mocks it is a symptom of a very side-effected programming style. If you cannot unit test most your business logic then you are probably mixing up your business level code with side-effecting code (like calling APIs or DBs). Personally I've found it better to split pure business logic and side-effecting logic as close to the edge (API endpoint handler) as possible. Then it i…
The 'business logic' for many apps consists entirely of calling other APIs and databases.
Re: Don't Use Mocks
#4I feel that if most of your tests relies on mocks it is a symptom of a very side-effected programming style. If you cannot unit test most your business logic then you are probably mixing up your business level code with side-effecting code (like calling APIs or DBs). Personally I've found it better to split pure business logic and side-effecting logic as close to the edge (API endpoint handler) as possible. Then it i…
If your database isn't involved in your business logic then you're probably significantly underutilizing capabilities of modern databases.
Re: Don't Use Mocks
#5Nah I'm about done working on rails codebases with 2+ hour CI cycles because developers insist on hammering a database in unit tests.
Re: Don't Use Mocks
#6Where I have found mocking useful or unavoidable is when we need to modify behaviour that is not in our control. This almost always is in calling a third party resource (api or store) or an sdk or library.
Everything else can be controlled and tested via DI.
Re: Don't Use Mocks
#7The point is: if your tests just assert which methods are called on dependencies with what arguments (or something close to that), they are extremely coupled and brittle. Almost any change in the implementation will require changing such tests. And by their nature, they probably test some minor low-level things, that are not all that valuable to assert anyway. Mocks enable and encourage this kind of testing.
Better tests would assert some kind of higher level properties that are much less likely to change. This often involves making the dependencies you inject during testing some more complete simulations of real implementations. Takes more up front effort to implement them, but can often be re-used between many tests.
Tests on one hand help you modify software over time, but on the other hand increase maintenance burden. Being good at testing doesn't mean just writing lots of tests, but being good at judging the value of a test vs the cost of having it, which is very context dependent in itself.
Re: Don't Use Mocks
#8I'm not sure I follow the argument. Use fakes instead of mocks, but if you change the dep1 to have a method add instead of addone, you still need to update the fake. The effect is the same as if you needed to update the mock setup. About the only benefit I can see, is if the fake is used in multiple tests and you only need to update it once.
Re: Don't Use Mocks
#9The point is: if your tests just assert which methods are called on dependencies with what arguments (or something close to that), they are extremely coupled and brittle. Almost any change in the implementation will require changing such tests. And by their nature, they probably test some minor low-level things, that are not all that valuable to assert anyway. Mocks enable and encourage this kind of testing. Better t…
This was an insightful comment. I shouldn't write tests that assert a method on my mock has been called, I should design a mock whose behaviour changes in response to interaction, and then assert that the relevant behaviour has indeed changed!
That change would still be the same amount of maintenance (if the underlying implementation changes, the mock will have to be updated to reflect that as well) but the test will communicate more clearly what the intention of the interaction is.
Re: Don't Use Mocks
#10The topic of software theory (articles, advices, recommendations) for testing is the biggest failure of this industry
Everyone is trying to figure out how to do it "right"(measuring by their needs)
and all of them struggle to realize that it is always context dependent - two different products, teams, companies may have different expectations and needs
I dont know how this happens that out of all arguable things in software engineering - is it that tests are the most chaotic ones, when up to the principle they are simple: if your code doesnt match specification, then scream!
Dont even get me on how TDD saves the world and is the only way how all software should be written (it is especially funny that tdd is accidentally successful by forcing api design first, yet ppl always argue for it due to red green transition and never due to api design first)
Also the concept of unit as in unit test may differ by kind of software
E.g unit test for parser may feel like e2e test for somebody who works in web apps