Hacker News Reader

Do you set up a new database schema for each unit test? If yes, that tends to be slow if you have many tests (hundreds or thousands), and if no, then you risk getting stateful dependencies between tests and they aren’t really unit tests anymore.

View on HN

Not OP, but I do this with SQLite in memory DB. If each unit only adds the tables the test needs, this is super fast, probably around 2ms per table.

Unless you use SQLite in production as well, this can give you a false sense of security, as there can be subtle behavior differences between DBMSs. Ideally you should always test with the same DBMS and same version as used in production.

This is the same risk with mocking/stubbing, but for integration tests it's important that you're testing with the actual system used in production.

Yep. I have very much been bitten by these differences. Particularly for some of the funkier SQL statements where SQLite and PG handle arrays very differently.

In our case, we decided it was a worthy trade off in terms of developer feedback times on our python microservices, because most of the SQL there is INSERT only. In our golang services which do 90% of the interesting SQL, we spin up PG in a docker container.

Don't need to do that, just run each test in it's own transaction, no?

Reply on news.ycombinator.com