This is really common usage, but I find it somewhat baffling. Once adopted, you have to either: - Refrain from using any Postgres features that don’t work [the

This is really common usage, but I find it somewhat baffling. Once adopted, you have to either: - Refrain from using any Postgres features that don’t work [the same way] in SQLite (so much for your code not knowing about your test environment!) - Maintain both in tandem and, presumably, test that they have the same behavior or… accept that they may not; in either case you have to accept that you might not know if your SQLite implementation is correct I don’t think the alternative is having code which knows about the test environment. Instead, it’s: test with the real service or set of services you use, and limit the surface area under test. That doesn’t mean you can’t use DI! It just means you have: - data access layer tests that hit Postgres (and any other supported provider) - unit tests of anything consuming the data access layer, injecting a provider which only produces results consistent with the behavior already tested in the data access layer At that point, why inject SQLite? You already ~know the results you can expect from the injected service… just return them.