4 ms·

Your thoughts on this reminds me of: https://martinfowler.com/articles/mocksArentStubs.html#ClassicalAndMockistTesting https://martinfowler.com/articles/mocksAr

• majormajor 7y ago
  Thanks for the link, I hadn't seen those terms before, but yeah, I have been debating it for a while with coworkers. I'm a bit in between the way described there, though, since I'll often happily leave other objects mocked as long as I know that my contract successfully called that object. I don't need to test all the way through their own implementation - there should be sufficient testing on that object to drive a refactor of it. I just want to support a refactor of me. My view is basically: "we're gonna have to restructure some of this code as future requirements come in, so let's make sure our tests ensure that the things we really want to happen do happen" (like an update being sent to the database or other backend service layer). I have similar hesitancy about applying a lot of design patterns early. Most of the places I've worked have been in the experimentation and rapid feature development stages of the business, with all development being internal development (rather than providing an SDK to others), so being able to change the code is more critical than being able to treat the code as more of a framework.