2 ms·

otoh, I worked with a guy who was so mock heavy that he actually wrote real mocks for hash table for each test. I worked with another guy who mocked out so muc

otoh, I worked with a guy who was so mock heavy that he actually wrote real mocks for hash table for each test. I worked with another guy who mocked out so much external behavior that he couldn't figure out why his stuff never worked, not doing the necessary work to ensure that his expectations of external behavior were actually still met ( if you're going to mock out external behavior, you need to add in tests that ensures your expectations are valid). There is a place for Mocks, but I have found the other varieties of test doubles to more useful...

convolvatron 4y ago
what is the place for mocks?
- Tainnor 4y ago
  External systems, unexpected error cases (which by nature of being unexpected can't really be triggered in a "natural" way), very generic code (e.g. instrumentation frameworks), major architectural boundaries, ... I agree that most people over-mock, though.
  - readthenotes1 4y ago
    External systems dependencies are better handled with stubs and fakes than mocks, in my experience.
    - Tainnor 4y ago
      That really depends on the case in question and on the particulars of the codebase. I wouldn't recommend mocking http libraries, database calls etc. - that usually leads to madness and impenetrable test setups. I would rather recommend to either use fake implementations (e.g. in-memory DB) or to only integration-test the boundaries of your interaction with the external system (that might or might not be hard to achieve). But I do like the pattern of wrapping calls to external APIs through a layer that I control - so that, for example, I may just write mailer.sendMessage(message) - and then that mailer interface seems like a good candidate for mocking.
- readthenotes1 4y ago
  In my experience, they are the test double of last resort. I used them to verify behavior, not outcome (as that's what expectations do), e.g., did I really call this method only once?
what-no-tests 4y ago
If I'm writing unit tests for #some_method, I'll mock anything that method calls outside of that method (so I can check how that method will respond to error conditions from calling those other methods). Unit tests != Integration tests, and the two must both exist otherwise I'll run into that situation where my unit tests work but the software doesn't.
- UglyToad 4y ago
  But do you not find the problem is you now end up with tests that assume the existence of #some_method with the tests tightly coupled to the internal logic and flow of that method? If you decide to refactor, every part of the system now has one or more tests that break because they mimic or clone each method 1:1 rather than testing input and output.
  - readthenotes1 4y ago
    Exactly the problem the 2nd guy had
  - what-no-tests 4y ago
    Perhaps, but if I refactor #some_method I only have to look in my unit tests where I describe #some_method and focus there. The integration tests should not have to be updated, since they only describe expected behavior -- unless the expected behavior must change as well. The coupling between unit tests and the methods they test is correct, IMO, because really how else are you supposed to test what #some_method would do when it tries to call #another_method but #another_method raises various different exceptions, or returns no results, or returns successfully? If the answer is "I only test happy paths" then good luck - you're not really testing anything.

convolvatron 4y ago

what is the place for mocks?

Tainnor 4y ago
External systems, unexpected error cases (which by nature of being unexpected can't really be triggered in a "natural" way), very generic code (e.g. instrumentation frameworks), major architectural boundaries, ... I agree that most people over-mock, though.
- readthenotes1 4y ago
  External systems dependencies are better handled with stubs and fakes than mocks, in my experience.
  - Tainnor 4y ago
    That really depends on the case in question and on the particulars of the codebase. I wouldn't recommend mocking http libraries, database calls etc. - that usually leads to madness and impenetrable test setups. I would rather recommend to either use fake implementations (e.g. in-memory DB) or to only integration-test the boundaries of your interaction with the external system (that might or might not be hard to achieve). But I do like the pattern of wrapping calls to external APIs through a layer that I control - so that, for example, I may just write mailer.sendMessage(message) - and then that mailer interface seems like a good candidate for mocking.
readthenotes1 4y ago
In my experience, they are the test double of last resort. I used them to verify behavior, not outcome (as that's what expectations do), e.g., did I really call this method only once?

what-no-tests 4y ago

If I'm writing unit tests for #some_method, I'll mock anything that method calls outside of that method (so I can check how that method will respond to error conditions from calling those other methods). Unit tests != Integration tests, and the two must both exist otherwise I'll run into that situation where my unit tests work but the software doesn't.

UglyToad 4y ago
But do you not find the problem is you now end up with tests that assume the existence of #some_method with the tests tightly coupled to the internal logic and flow of that method? If you decide to refactor, every part of the system now has one or more tests that break because they mimic or clone each method 1:1 rather than testing input and output.
- readthenotes1 4y ago
  Exactly the problem the 2nd guy had
- what-no-tests 4y ago
  Perhaps, but if I refactor #some_method I only have to look in my unit tests where I describe #some_method and focus there. The integration tests should not have to be updated, since they only describe expected behavior -- unless the expected behavior must change as well. The coupling between unit tests and the methods they test is correct, IMO, because really how else are you supposed to test what #some_method would do when it tries to call #another_method but #another_method raises various different exceptions, or returns no results, or returns successfully? If the answer is "I only test happy paths" then good luck - you're not really testing anything.