Hi Michael,

Thank you so much for your comment. If you have discovered that we have two competing definitions of Unit Tests, this is already a win. There is a big gap out there.

Well, the idea of testing behaviors, not code, comes from the original definition of Kent Beck. (I love this tweet: https://twitter.com/KentBeck/status/1182714083230904320?s=20&t=bXR99o4QIWP0DC-vKhKMhQ ).

The reason why TDD tests avoid mocks is that they are testing the system behavior, not pieces of code. With TDD, the code is not supposed to exist before the test, so it makes no sense to start creating mocks of things that does not exist (or you should ignore).

In the line of your comment, there are only two reasons why to mock something with TDD:

1. Something is slow, and you need to go faster.

2. Something messes with the state of the program, and because you need to isolate tests from each other (not code from each other) you create mocks.

The example of the database is marvelous, it satisfies both reasons. If you change a database by an equivalent in memory "fake", then it goes faster, and you can purge it for every test. And the same for the service, they are slow and may interfere from service to service.

Anyway, it is deeper than that. And there are tons of techniques to avoid mocks:

- if your application is modular, and you can build pieces, probably you can avoid mocks most of the time. For example, you do not need a database or API to check the errors of a form validation. So, it often happens that you can avoid them and only have a few of them that really requires a mock.

- I have a technique, that with TDD and back and front developments, and I use snapshots to pass information from back to front and check correctly using real data. I have examples here and here. I guess that it would look like Pact, but I am not sure, it is in my pending to study list.

- and of course, if you use a database in memory, it is, in fact, a database. So... it is a mock, but it is not a mock.

I see that this comment got a little bit long. I'll try to do a longer version as an article.

Thanks!