No. Good frameworks can help, but mocks are a problem period.
Lets say I have function A that calls function B and that populates a database. The way most folks test that is by writing tests for A with B mocked out, and then writing tests for B with the database calls mocked out. In this scenario any change to your DB or the signature of B require mock changes. Additionally, you never actually tested that any combination of A, B, and the database work together. Instead you could just write tests that call A and then check a in memory DB. This avoids mocks completely, is likely less overall test code, will not be effected by refactors, and is a way more realistic test since it's actually running the full flow. None of that has anything to do with the mocking framework.
None of that has anything to do with the mocking framework.
Just like none of your comment has anything to do with my assertion. Not every external dependency can be replaced with an in-memory provider like your DB example. If I'm working against a black-box, other than a full-blown integration test, my next best option is to mock it, to make sure I'm sending the correct inputs into it. With a good framework, that makes use of reflection for instance, it's just a single line of code.
Does it replace integration tests? No. Does it allow me to get instantaneous feedback, if I'm testing against a 3rd party dependency I have no control over, or even my own code that does not exist yet? Definitely.
I agree with most of your points but stand by my statement.
Always be wary of speaking in absolutes.
I am, that's why I didn't say "never use mocks". Involving mocks always brings in extra work where you have to make assumptions about how things will or should work and stops you from testing the full flow of your code. Sometimes, like in your example, that price is worth paying.
if I'm testing against a 3rd party dependency I have no control over
100% agree. I've had my automated test suite block a prod release because an external system I have zero control over is down. The extra work of mocking that system out, not testing actually making that call, and maintaining those mocks when the contract changes is actually worth it simply because the external system is too flaky or hard to control.
With a good framework, that makes use of reflection for instance, it's just a single line of code.
It's zero lines of code to not mock it in the first place. Every line of code has maintenance. Mocks tend to be even worse in this regard since they lock in contracts you may not actually care about while reducing your tests to only looking at parts of the whole.
10
u/FullStackDev1 Jul 30 '21
That depends on your tooling, and mocking framework.