Stop Writing Database-Dependent Tests — Mock Your Data Access Layer Hello guys, unit testing is supposed to be fast, isolated, and predictable. Yet, many developers still fall into the trap of …

Java Revisited's resource offers insights, tutorials, and resources for Java developers and enthusiasts. Readers can learn about Java programming, JVM internals, and enterprise Java technologies. With articles, tutorials, and code examples, Java Revisited provides  guidance and expertise for mastering the Java language and ecosystem.

Javarevisited

Database-dependent tests are slow, fragile, and blur the boundaries between unit and integration testing. Mocking the data access layer through interfaces and dependency injection enables fast, isolated unit tests that focus on business logic rather than infrastructure. The recommended approach is to use mocks for 90% of tests while reserving database-touching integration tests for the remaining 10%, ensuring high coverage without sacrificing development speed.

Stop Writing Database-Dependent Tests — Mock Your Data Access Layer

<blockquote>
They’re fragile.
Changes in schema or seed data can break tests unrelated to the code being tested, leading to false negatives and wasted debugging time.
</blockquote>
i don’t see how this is a bad thing, aren’t tests supposed to fail when they break something?? how would the schema change if you didn’t change it? and if you did, then it’s your job to fix what your changes broke?
I can’t seem to agree with this point and “They’re hard to maintain” honestly; i understand the difficulty of keeping tests in check, but isn’t that something we want for the purpose of keeping the system in a functional state all the time?

The author seems to rely heavily on ORM layers, which I find problematic. ORMs can speed up early development but often lead developers to treat the database as a generic data bin, ignoring its real capabilities. Each database—Oracle, Postgres, SQL Server, MySQL—has its own strengths that an ORM tends to hide.
I prefer a clear separation between the application logic and the database layer. The application should define its own data-access layer with well-structured functions that can be easily mocked, while the database layer can then be implemented according to the chosen system. This allows moving parts of the logic between the app and the database depending on the project’s needs.
Maybe this is what the author actually intended to suggest?
Everybody is free to use methods that fit their requirements, and I appreciate that the author shared his perspective. I’ve been developing databases since Oracle 6, so I may simply have a different point of view.

Mocking database calls can lead to behavior that never happens in real life. I used to do that, hexagonal architecture, tdd and mocked data access layer. It led to dead code that only was running in tests.

Problem with mocks is that after a while is that you’re testing your ability to mock something accurately. For a data store I’d stick to using the real one via something like testcontainers - far easier to set up and keep it the same as live / production systems.

Fragile and hard to maintain? I don’t agree. I always prefer an integration/end-to-end test that covers everything in my application flow. That includes database calls. THIS is easier to maintain, because you can refactor or move around code and your test will still work. No need to fix existing tests after every single chance.
Yes, they are slower, but based on my experience they make your life much easier in the long run.