[jjrumi]

In my case, most of the time mocks are used to avoid Database interactions: They are dangerous for writing and slow for reading.

The best thing I've run into lately have been "mocking" the DB creating a copy (temporary tables with only the needed data) of the tables that the code interact with.

This way you create a "mock" of the data you're going to work with and code the test getting a more reliable test in my opinion.

[stuhacking]

Testing a DB connection sounds more like integration than unit testing.

Mocks are used to fake things that add significant overhead but no value. If you have a suite of 1000 unit tests, you really don't want half of them making actual database requests.

Simply making 'safe copies' of the database data does not solve the problem that Mocks are intended to solve.

[MartinCron]

In my experience, it's all about layers.

I do both, I have a set of integration tests create a "safe copy" of the database and populate it with seed data, so I can trust that my data-layer stuff works correctly, while my pure unit tests interact with a super-fast fake database implementation.

I actually wrote the in-memory fake db before I wired up a real database. It made the early iterations much faster without having to make changes to multiple layers. I could have not bothered with writing tests against a "safe copy" of the database, but I sleep better knowing that the assumptions about how the persistence types work in my unit tests are validated by my integration/data tests.

[jjrumi]

It's not a "safe" copy, it's a set of known data in memory that fakes the DB connection and reacts as it will with a real DB connection.

And yes, I have 500+ UTs.

[stuhacking]

I'm sorry, I misunderstood the situation you described.