5 ms·

I write unit tests selectively to capture unwritten rules about how some functions need to act. It is a better form of documentation. Otherwise, I lean on wha

I write unit tests selectively to capture unwritten rules about how some functions need to act. It is a better form of documentation. Otherwise, I lean on what you are describing: actually testing a system against the outer "api layer" that is interacted with by external users be it a UI or an actual api. I avoid mocking like the plague unless it truly is an external system I have no control over. Then I might mock as a form of documentation about expectations. I was involved in a project recently that uses the "clean architecture" approach where every layer was abstracted and everything was mocked. Honestly it was a major turn off on two levels: I deeply dislike the "clean" architecture based on this single experience alone and I found my deep dislike of heavy mocking to be rekindled.

teknopaul 4y ago
Been in that "everything mocked" scenario too. I try to mock as little as possible too but ensure that as much as possible can be mocked, because very often that is path of least resistance for a specific test. I've seen code with so much mocked that many unit tests failed to test anything other than behaviour of mocks. Not sure I'm comfortable with test code and switches being deployed as an alternative. I find supporting different types of test to be a benefit. Seems to me if you have test infrastructure in the code that will limit options. I have seen code that activly prevented mocks that was impossible to test.
- u801e 4y ago
  > I've seen code with so much mocked that many unit tests failed to test anything other than behaviour of mocks. One example of this was a test that passed because of the expected behavior as determined by a mock, but the code failed in the staging environment because the underlying library changed its method signature to take some parameters in a different order. To me, this basically was a signal that that particular test and tests like it were essentially useless in determining whether the code was really in a working state.
  - flippinburgers 4y ago
    This is the major achilles heal of mocking that I find to be most bothersome. If at all possible I try to have at least a happy path subset of real tests hitting real 3rd party apis if I possibly can.

teknopaul 4y ago

Been in that "everything mocked" scenario too. I try to mock as little as possible too but ensure that as much as possible can be mocked, because very often that is path of least resistance for a specific test. I've seen code with so much mocked that many unit tests failed to test anything other than behaviour of mocks. Not sure I'm comfortable with test code and switches being deployed as an alternative. I find supporting different types of test to be a benefit. Seems to me if you have test infrastructure in the code that will limit options. I have seen code that activly prevented mocks that was impossible to test.

u801e 4y ago
> I've seen code with so much mocked that many unit tests failed to test anything other than behaviour of mocks. One example of this was a test that passed because of the expected behavior as determined by a mock, but the code failed in the staging environment because the underlying library changed its method signature to take some parameters in a different order. To me, this basically was a signal that that particular test and tests like it were essentially useless in determining whether the code was really in a working state.
- flippinburgers 4y ago
  This is the major achilles heal of mocking that I find to be most bothersome. If at all possible I try to have at least a happy path subset of real tests hitting real 3rd party apis if I possibly can.