I was very surprised to see all of the negative sentiment on the other thread [1]. The prevailing opinion seemed to be "just use a real database," specifically

I was very surprised to see all of the negative sentiment on the other thread [1]. The prevailing opinion seemed to be "just use a real database," specifically in the contexts of testing. As in, why test against a mock adapter when you could test against your actual DB (or sqlite), with very little concern given to the adapter pattern in and of itself. But I think that sentiment misses two points: 1. The adapter pattern is a pleasant API from a user perspective, regardless of your approach to testing. 2. As far as testing goes, why not both? You should absolutely have functional/integration tests against a real database, but pure unit tests are also useful for highly portable test environments. This is especially true in larger orgs where you can't just ship a Dockerfile to everyone to ensure they all have a consistent dev environment. There was also a concern about adapters hiding the SQL that gets run, or making more queries than is needed, which makes it difficult to debug query performance. I think this is the most valid argument against the pattern, but it's not an insurmountable problem. [1]: https://news.ycombinator.com/item?id=36890681 https://news.ycombinator.com/item?id=36890681