Hacker News new | ask | show | jobs
by chromatic 5000 days ago
This keeps your tests isolated and fast.

No, writing good tests keeps your test isolated and fast. Creating lots of mock objects distracts you from writing good tests, because what you're testing is your ability to 1) write mock objects that conform to the ad hoc interfaces you've produced and 2) maintain those mock objects when those ad hoc interfaces change.

If you want to know if your code works, you still have to test if it all works together.
2 comments
latortuga 5000 days ago
I totally agree - if you want to know if it works, you have to test it all together; however, that's not how I approach unit testing. I don't think mock objects are a good idea during integration testing with perhaps a few exceptions such as an external web service. When you want to ensure that your application works, testing the steps that actual users will go through is the way to know and mocking or stubbing functionality won't help.

Personally, I view unit testing differently. I see it as ensuring that my object gets the right data and sends the right messages. If you start adding tests for things like "did it save to the database" or "did it find 3 results" you're now involving your persistence layer with your testing of business logic. It's a tangential concern.

link
urbanautomaton 5000 days ago
But if you're having to create lots of mock objects, that's a huge signal that your objects are tightly coupled, and that not only are you writing a bad test, you've written a bad subject-under-test.

Yes, you still have to write integration tests. But the discipline of testing your objects in isolation and outlining the objects they collaborate with is a major benefit of using test doubles, not a downside. If you can't reason about your objects in isolation, how can you expect to reason about them in aggregate?

link
chromatic 4998 days ago
If you can't reason about your objects in isolation, how can you expect to reason about them in aggregate?

I don't use my objects in isolation.

Maybe I can mock up some factory which creates model objects outside of my persistence mechanism, but what value is that? I care that when I create an object in response to an action from a real user the persistence mechanism produces the correct object.

I happily bulk load testing data into my persistence mechanism for testing purposes, but I see almost no reason to mock it for tests.

link