3 ms·
Same. Not only to ensure I wrote queries or scopes correctly, but also because I like to add extra validation constraints to be sure my application code can't
by waffle_ss 11y ago
Same. Not only to ensure I wrote queries or scopes correctly, but also because I like to add extra validation constraints to be sure my application code can't sneak junk into the database.
How can I really ensure my CHECK constraints / DOMAINs, unique indexes, RAISE EXCEPTION in insert/update triggers, etc. are correctly implemented if I'm not testing against a real Postgres database?
- whoisthemachine 11y agoI would recommend writing tests specifically for testing the PostgreSql changes, ideally you can write them purely in PostgreSql, maintaining a nice separation of your code and your SQL. Also, the only thing that should really need proper testing are stored procedures, your check constraints can't possible be so complicated that they warrant tests. The unit tests that test out your business logic should use mock data - it's just much more reliable, reproducible, and faster.