11–20 of 85 posts
Nah I'm about done working on rails codebases with 2+ hour CI cycles because developers insist on hammering a database in unit tests.
There are the pushing-the-edge-of-excellence folks, constantly refining methods and approaches, who tend to be passionate about the holistic benefits of testing.
And there are the folks who write convoluted tests that, when you dig into them, just confirm that String's .equals() works OK. DAO/database tests which have mocking going on to the point where you're faking a database response of "hello", say, and then checking "expected response == hello". Then yay our test passes!!
Personally I feel our energy should somehow be spent collectively on getting the latter group to just not write total garbage, and that the bar for "good enough" is really not that high, after which we get into diminishing-returns territory. And I think, personally, that mocking is responsible for so much confusion in folks that ultimately don't really know what they're trying to accomplish.
Nah I'm about done working on rails codebases with 2+ hour CI cycles because developers insist on hammering a database in unit tests.
There are entirely separate communities IMO when it comes to automated tests. There are the pushing-the-edge-of-excellence folks, constantly refining methods and approaches, who tend to be passionate about the holistic benefits of testing. And there are the folks who write convoluted tests that, when you dig into them, just confirm that String's .equals() works OK. DAO/database tests which have mocking going on to th…
The test suite I do run is the one where I hit "run" in my IDE and then it lets be jump to what failed and debug seconds later.
That, IMO, is what mocking is about: making the tests fast and easy to run so they actually are.
If anything mocking is useful for verifying that something is called whether that be a service or a repository method.
Equally mocking things like mappers is overkill, a nice balance is to inject some mocks and some "real" instances of dependencies into the class that is under test.
The added benefit is that you are testing the dependencies (if the mapper for example) are working.
Nah I'm about done working on rails codebases with 2+ hour CI cycles because developers insist on hammering a database in unit tests.
This way if a mocked test fails you find out much faster.
1. You still need to update the fake object once you gonna add a new behaviour.
2. Fake object has a tendency to become logic heavy. Someone will add a stupid-not-needed-map to test some shit you don't need to test in this unit\layer.
3. You only need to mock the behaviour you depend on. If you've added new Method and you need to mock it despite the fact you're not using it in the code you're testing - its a bit weird and smelly. Consider rethink SOLID principles at least.
4. Go. Gen. Effectively you can automate mock generation. Debatable but it's cool.
Just. Keep. Things. Simple. Depend on what you need. Mock behaviour you need. Try to test flattened structure - do not test the layer below the one you're testing ATM (unit tests).
Having a title with a blanket statement like "Don't Use Mocks" is either plain wrong or clickbait. In this case, it seems it is both wrong and clickbait. Such blanket statements and clickbaits specifically trigger people to get into a long-winded debate (ironically, my own comment here is a case in point) about something that is obvious and otherwise uncontroversial.
If you are a small or medium project that doesn't make many RPCs just test with the real thing.
Once I got to google which makes many RPCs in every layer it just wasn't viable to not use mocking. I use mocks in almost every thing.
Yes, it makes unit tests brittle and couples to implementation. But unit tests are cheap and often need to be changed anyways. It also allows you to have control over certain situations like what happens if an error occurs. Which can be hard to test for in integration tests.
In short I feel like avoid mocks if you can but embrace them if you can't.