I disagree - I always test a real database, never mock it. This is because in my embedded domain we often ship with an empty database, so it is no big deal to add just the tables I need with whatever data I want, and then test it. Sqlite makes this easy for us.

Likewise filesystems on modern operating systems are fast (there is a cache): I cannot measure the time difference I save mocking the filesystem calls out, so it is easier and safer to just work with files I create in the tests. It might some effort to ensure my tests put files in places where they won't collide with other tests, but this isn't hard once you have the idea in place. Since our plan was put into the code early on most people don't even consider bypassing it for some hard coded locatoin and so it is easy to use the plan on test files located in a different location.

Note that the above is specific to my domain. I understand that some of you deal with one database so there is no abstraction that lets you substitute a test database you create on the fly, something not worth fixing since you still cannot afford a license for every developer and CI machine. I'm sure there is a similar argument against using a file system.

The point: before saying don't use something expensive in tests do a benchmark: prove it actually is expensive. You may be lucky like me and discover that databases and filesystem access in tests are not expensive!