4 ms·

>Your tests reduce to: response = "derp" assert response == "derp" I do not agree. Mocking doesn't mean you assert what you just mocked, mocking let's you test

>Your tests reduce to: response = "derp" assert response == "derp" I do not agree. Mocking doesn't mean you assert what you just mocked, mocking let's you test a piece of code in isolation. When writing unit tests I mock all the dependencies, even if I control them, as I only want to test a particular function at a time and not the external code. If you want to test more, then you can write integration tests or end to end tests, but that is another matter.

deleted 3y ago
[deleted]
bot314159 3y ago
I was going to write almost this same comment. It felt like the author wanted to test all of their dependencies in their unit tests, like that was the part of the system they didn’t trust. They don’t seem to value testing that their code functions as intended given expected behaviour of the dependencies.
- ebiester 3y ago
  We rarely write unit tests because we are worried about missing an edge case while writing the code. It's often faster to manually test than write the automated case. We write tests because we need a specification that lives past that moment in time. We also write tests because other parts of the system change because business requirements change in other parts of the system, and the necessary conversation doesn't happen. I trust what the system does on July 9, 2023. I don't trust what the system will do on July 9, 2024. How do I guard against that?
MoreQARespect 3y ago
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.
rad_gruchalski 3y ago
> When writing unit tests I mock all the dependencies I dislike this approach because whenever any of those dependencies change, I need to change all mocks. I prefer designing my code in such a way that dependencies can be easily pulled into a test instead of mocking. It may be more work upfront but pays off in the future. Instead of spending the time to write and maintain mocks, spend the time to ensure dependencies can be pulled into a test.

deleted 3y ago

[deleted]

bot314159 3y ago

I was going to write almost this same comment. It felt like the author wanted to test all of their dependencies in their unit tests, like that was the part of the system they didn’t trust. They don’t seem to value testing that their code functions as intended given expected behaviour of the dependencies.

ebiester 3y ago
We rarely write unit tests because we are worried about missing an edge case while writing the code. It's often faster to manually test than write the automated case. We write tests because we need a specification that lives past that moment in time. We also write tests because other parts of the system change because business requirements change in other parts of the system, and the necessary conversation doesn't happen. I trust what the system does on July 9, 2023. I don't trust what the system will do on July 9, 2024. How do I guard against that?

MoreQARespect 3y ago

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.

rad_gruchalski 3y ago

> When writing unit tests I mock all the dependencies I dislike this approach because whenever any of those dependencies change, I need to change all mocks. I prefer designing my code in such a way that dependencies can be easily pulled into a test instead of mocking. It may be more work upfront but pays off in the future. Instead of spending the time to write and maintain mocks, spend the time to ensure dependencies can be pulled into a test.