Totally agree. Feature/acceptance TDD (e.e. BDD) is essential and can drive your design as well as reduce bugs. Unit-test TDD on the other hand, presumes a level of implementation knowledge that's lacking in many development cases. Often, you don't know the API of a class until you actually write it. And then, even more often, you get to change that API multiple times, as you progress with writing the rest of the system.
Unfortunately, some people are blind followers of the cult of unit-test TDD and you can usually tell by the level of mocking and stubbing found in their test code. So, yes, well said!
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.
Totally agree. Feature/acceptance TDD (e.e. BDD) is essential and can drive your design as well as reduce bugs. Unit-test TDD on the other hand, presumes a level of implementation knowledge that's lacking in many development cases. Often, you don't know the API of a class until you actually write it. And then, even more often, you get to change that API multiple times, as you progress with writing the rest of the system.
Unfortunately, some people are blind followers of the cult of unit-test TDD and you can usually tell by the level of mocking and stubbing found in their test code. So, yes, well said!
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.