"The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing."
I've been working in a classical TDD style for the past 8 years, after at least that many years of Mockist TDD. A code base built in classical TDD style is much easier to maintain and change, but it does require more test setup which can easily be pulled into re-usable test data scenarios etc. We'll use fakes for services that are external(S3, DynamoDB, third party APIs, etc), we'll use real DB code pointing to h2 instead of say postgres other than that there's no test doubles. I would not go back to using mocks by choice.
Why would you want to? when the same unit test coverage will run under 1 minute, and be smaller easier to understand/change tests and can all be done on your laptop.
it all depends on your definition of unit/integration, what I am talking about as unit tests you may very well be talking about as integration tests...
one of the main points I was making is you shouldn't have significant duplication in test coverage and if you do, I'd much rather stick with the unit tests and delete the others.
Integration, E2E, and smoke tests are generally slow, flakey, hard to write. They should not cover/duplicate all the cases your unit tests cover.
They are good at letting you know all your units are wired up and functioning together. In all the codebases I've ever worked in, I would feel way more comfortable deleting them vs deleting the unit tests.
for better content on the subject:
https://martinfowler.com/articles/mocksArentStubs.html
https://martinfowler.com/articles/mocksArentStubs.html#Class...
https://www.thoughtworks.com/insights/blog/mockists-are-dead...
"The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing."
I've been working in a classical TDD style for the past 8 years, after at least that many years of Mockist TDD. A code base built in classical TDD style is much easier to maintain and change, but it does require more test setup which can easily be pulled into re-usable test data scenarios etc. We'll use fakes for services that are external(S3, DynamoDB, third party APIs, etc), we'll use real DB code pointing to h2 instead of say postgres other than that there's no test doubles. I would not go back to using mocks by choice.