4 ms·

I think you miss the point. With a lot of code once you've mocked out all the dependencies you're not left with anything to test apart from assert derp == derp.

• bot314159 3y ago
  > you're not left with anything to test Is this really that common? Maybe I'm out of touch, but I find it hard to imagine much code that just strings calls to dependencies together and has none of its own behaviour. Surely decisions are being made based on the dependencies behaviour? Isn't that worth unit testing?
  • MoreQARespect 3y ago
    Yes. For example, most CRUD apps are like this almost by definition. It's more common for domain logic to be fairly simple and smeared across multiple systems and languages, though - e.g. some is in SQL, some is in a separate microservices, some is in module A and some is in module B. In either case unit tests end up being mimetic tests: assert derp == derp.
  • watwut 3y ago
    I worked with a lot of code like that. The decisions made on dependencies were trivial. Bugs happened when dependency answered with something we did not expected. Or when we send away wrong data (not knowing parameter X is mandatory when Y equals Z sort of thing). Meanwhile, all those mocks were just clutter. Integration tests made a whole lot of sense. Mocks did not.