IMO, databases is often an integral part of the program and should be part of the test (a real database in a docker image).

For instance, if you are not relying on unique constraint in the DB to implement idempotency you are probably doing something wrong, and if you are not testing idempotent behaviour you are probably doing something wrong.

I have plenty of tests actually calling database. Maybe it is not a proper unit test, but it is not a problem for me.

I want test to protect me against regressions, and I do not really care how they are classified.

It really depends on your definition of unit. In the London school of TDD, no, a unit cannot extend across an I/O boundary. The classicist school takes a more flexible, pragmatic approach.

I'd love to know the story behind "the London school".

It's all in this book: http://www.growing-object-oriented-software.com/

Intriguing. Thanks!

You mean fakes/stubs, right? Unless you're testing whether you're correctly implementing the protocol exchange with an external party, you don't need to record the API calls.

How do you test your mocks?

How do you test the tests that are testing your mocks? That said verifying mocks are a great help - they won't let you mock methods that don't exist on the real object.

Some mocking libraries, like the VCR library in ruby, can be turned off every now and then so you tests hit real endpoints. It is worth doing from time to time.