4 ms·
> progres native json and array fields - good luck running your tests on sqlite you're not testing what you actually run in production, then what are you testi
by satyanash 7y ago
> progres native json and array fields - good luck running your tests on sqlite
you're not testing what you actually run in production, then what are you testing? If you just need to test in-mem behaviour, mock the DB completely; instead of expecting compatibility for vendor specific features across vendors.
- bayesian_horse 7y agoI'd say the sqlite backend and using it in testing is mostly useful for reusable django apps that are supposed to be used in a wide variety of projects. Most of the code I write in Django would never need to be SQLite-compatible, even if a lot of it would be. The SQLite compatibility is almost like a relict from a time when setting up RDBMSs was difficult and slow.
- kennydude 7y agoIf so, don't use things specifically in the Postgres contrib package of Django? The package is built that way for a reason
- Scarblac 7y ago> Most of the code I write in Django would never need to be SQLite-compatible, Then don't run your unit tests against SQLite, run them against Postgres.
- nnq 7y agoHmm... can one test use in-mem db mocking with django.contrib.postgres fields? I'll definitely look into this, not a solution for existing projects bc of legacy baggage, but probably the right way to do it. Problem in practice is that you yes what you really want is to mock the db completely, but practically speaking existing code is to entangled with the db adapter specifics, so you end up with running with a "fake real db" :|
- Scarblac 7y agoCan you write the tests so that you create object instances and not save them to a database at all? You don't need to test the ORM and database, after all, just your code.
- collyw 7y agoThe closer you keep things to production, the more likely you are to catch errors that will occur on production.
- nnq 7y agounit tests, yeah, but if you try to get "the most bang for the buck" in like "test a lot with zero/little effort" you'll end up with a layer of "integration tests": that (1) set stuff in db, (2) do stuff, (3) read stuff from db and assert its correctness... A sane ORM would not actively hinder this scenario even cross-dbs or with memory-mocked-dbs, but Django's does!
- djd20 7y agoI don't see the issue - you're asking it to support a feature of one database on another, something it never claims to do. You need to use the same database for testing that you use in production.
- candu 7y agoFor database testing, I often use a "ramdisk", or in-memory filesystem: sudo mount -t ramfs -o size=512m ramfs /path/to/mount/point, initdb, pg_ctl start. (There's a bit more bookkeeping to generate passwords, store them to /path/to/mount/point/.pgpass, etc.) You can tear it down afterwards with pg_ctl stop, sudo umount /path/to/mount/point. I'll put the necessary commands in start / stop scripts, then call those from within the beforeAll / afterAll hooks of whatever testing framework I'm using. It's definitely slower than mocking, and therefore not really suitable for unit tests - but it's great for repeatable, isolated integration tests (continuous or otherwise).
- bayesian_horse 7y agoSounds like a job for docker or CI systems.