Thread: Unit tests and foreign key constraints
Hey All,
I've started trying to use foreign key constraints in my schema but it seems to make it more difficult to write unit tests that touch the database because each test now requires more setup data to satisfy the foreign key constraint. (I know some say your unit tests shouldn't touch the DB but the more full stack tests I have, the better I sleep at night :-))
I wondered if anyone else has run into this problem and found a good strategy to mitigate it. I thought I might be able to make these constraints deferred during a test run since I have automatic rollback after each test but even after "set constraints all deferred", I still got a foreign key violation during my test run if the test tries to insert data with a non-existent foreign key.
Cheers,
Andy
On Thu, May 21, 2015 at 12:39:01PM -0700, Andy Chambers wrote: > Hey All, > > I've started trying to use foreign key constraints in my schema but it > seems to make it more difficult to write unit tests that touch the database > because each test now requires more setup data to satisfy the foreign key > constraint. (I know some say your unit tests shouldn't touch the DB but the > more full stack tests I have, the better I sleep at night :-)) > > I wondered if anyone else has run into this problem and found a good > strategy to mitigate it. I thought I might be able to make these > constraints deferred during a test run since I have automatic rollback > after each test but even after "set constraints all deferred", I still got > a foreign key violation during my test run if the test tries to insert data > with a non-existent foreign key. Foreign keys aren't deferrable by default, you have to create them that way... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > He who writes carelessly confesses thereby at the very outset that he does > not attach much importance to his own thoughts. -- Arthur Schopenhauer
Attachment
I know some say your unit tests shouldn't touch the DB but the more full stack tests I have, the better I sleep at night :-))
Unit tests really should be about testing individual bits of logic. Does a single method do the desired thing, and not the undesired thing... Ideally, your data access layer should be interchangeable, ie: use a real database record in production, but use a mock database record for unit tests.
I would consider database access to be an integration test, something that you run periodically but not at every commit.
I wondered if anyone else has run into this problem and found a good strategy to mitigate it.
Shouldn't failling to insert due to FK violation be considered an integration test failure? You may want to beef up your tests to make sure the necessary rows get inserted in the right order. Another option would be to automate the creation of a complete set of test data... using psql to load a dump, or possibly CREATE DATABASE testdbcopy WITH TEMPLATE testdb.
Integration tests can be costly to maintain with little ROI, tread carefully...
-Dave
On Thu, May 21, 2015 at 01:33:46PM -0700, Dave Owens wrote: > > > > I know some say your unit tests shouldn't touch the DB but the more full > > stack tests I have, the better I sleep at night :-)) > > > > Unit tests really should be about testing individual bits of logic. Does a > single method do the desired thing, and not the undesired thing... > Ideally, your data access layer should be interchangeable, ie: use a real > database record in production, but use a mock database record for unit > tests. Nice in theory. But if you use Postgres features like timestamptz calculations and hstore, it's generally way easier to run your unit tests on an actual PostgreSQL database. Otherwise you're going to spend all your time working around the fact that your mock database is not the real thing (and running into bugs in your emulation layer). Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > He who writes carelessly confesses thereby at the very outset that he does > not attach much importance to his own thoughts. -- Arthur Schopenhauer
Attachment
On Thu, May 21, 2015 at 1:34 PM, Martijn van Oosterhout <kleptog@svana.org> wrote:
Foreign keys aren't deferrable by default, you have to create them thatOn Thu, May 21, 2015 at 12:39:01PM -0700, Andy Chambers wrote:
> Hey All,
>
> I've started trying to use foreign key constraints in my schema but it
> seems to make it more difficult to write unit tests that touch the database
> because each test now requires more setup data to satisfy the foreign key
> constraint. (I know some say your unit tests shouldn't touch the DB but the
> more full stack tests I have, the better I sleep at night :-))
>
> I wondered if anyone else has run into this problem and found a good
> strategy to mitigate it. I thought I might be able to make these
> constraints deferred during a test run since I have automatic rollback
> after each test but even after "set constraints all deferred", I still got
> a foreign key violation during my test run if the test tries to insert data
> with a non-existent foreign key.
way...
Ah that's what I was missing. Thanks!
--
Andy