6 ms·
> Use sqlite :memory: for tests Then you run into issues where the functionality works on SQLite, but not on your real database.
by pyre 11y ago
> Use sqlite :memory: for tests
Then you run into issues where the functionality works on SQLite, but not on your real database.
- bliti 11y agoMay not work. Given the use of ORMs these days, this is a smaller issue. Though it still requires attention. Having the tests run quicker allows for better use of the programmers time
- pyre 11y ago> Given the use of ORMs these days, this is a smaller issue The ORM can't abstract away all differences between databases. For example, SQLite doesn't have Numeric type, so all of the Numeric(10, 2) fields on (e.g.) my SQLAlchemy (a Python ORM) models will trigger warnings when saving to a SQLite database.
- bliti 11y agoHence the sentence that follows after the one quoted. It does require attention. Just a bit less. In a sea of issues, reducing the importance of any might probably ease development in some way.
- sbov 11y agoWhere I work, tests have two modes: quick and long. Quick mode gets in memory treatment. Long mode doesn't. Anything that goes live will undergo a long mode test beforehand.
- hinkley 11y agoWe would run those tests a couple times a week, and the memory tests idealy on every successful build (we chained the builds so we never bothered to run the DB tests if the unit tests had already failed). Strictly speaking it's also possible to get subtle differences in behavior across OSes. Especially if you have a race condition you don't know about yet. I always tend to encourage more diversity (carefully spent).
- Osiris 11y agoI run a script that mounts a RAM drive and copies my postgresql database into the drive. I use tablespace to force Postgresql to look at the RAM drive for the database data. That way I am testing my queries against the same database engine but get the benefit of avoiding disk IO.
- curun1r 11y agoSQLite might be the easiest to configure, but some other RDBMSs have an option to run in memory too (e.g. MySQL's MEMORY storage engine). Also, as a last resort, you can always configure the DB to write to an in-memory file system. This strategy is, in essence, mocking the FS layer in DB tests.
- TylerE 11y agoOften those modes don't have the same semantics, which is dangerous for testing.
- coldtea 11y agoAfter some point it's diminishing returns though. Obviously nothing can be 100% tested.
- TylerE 11y agoOften those modes don't have the same semantics, which is dangerous for testing.
- TylerE 11y agoOften those modes don't have the same semantics, which is dangerous for testing.
- pilif 11y agoyou assume that SQLite supports all the querying features I'm using (hint: it doesn't).
- pyre 11y agoWell, those sorts of things cause the tests to immediately fail, and you realize the error of your ways. It's more deadly when you tests pass, but behaviour on production is different.