I will say right now that I'm all for mocking in your unit tests. But that's because I'm all for Unit Tests being the test of a single Unit, instead of a whole. To my mind, the hierarchy goes:
Unit Test - Tests a single Unit (Class, Module, etc) in isolation. This will test that it calls it's dependants correctly, and that it produces the correct outputs from it's inputs
Integration Test - Tests a collection of Units all together. This might test that a controller, retriever, and DAO all work correctly in conjunction. There should be no mocks in here (With the possible exception of any calls to external systems)
Acceptance Test - Tests that the running system as a whole works. Instead of testing the controller, this will test by making HTTP calls to a running system, or by running a browser pointing at the webapp.
Wasn't arguing against mocking/stubbing, just the level of it in some codebases, which for me is a code smell. That's why I think it's sometimes better to write unit-tests only after you have all your dependencies and class APIs figured out.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I will say right now that I'm all for mocking in your unit tests. But that's because I'm all for Unit Tests being the test of a single Unit, instead of a whole. To my mind, the hierarchy goes:
Wasn't arguing against mocking/stubbing, just the level of it in some codebases, which for me is a code smell. That's why I think it's sometimes better to write unit-tests only after you have all your dependencies and class APIs figured out.