Django, Unit Tests randomly fail from Postgres Integrity-Errors and Race Conditions

I’ve been battling an issue with our django unit tests having random failures from either

  • IntegrityErrors from models created by FactoryBoy even though all UnitTests use the Django’s TestCase base class that does the atomic.transactions. Also, have configured for various FactoryBoy objects to use the class Meta: attributes to use a get_or_create.
  • Also, have a view tests that brute spams object creation using freezegun over a timepsan and that will randomly fail when it asserts records in the database.

All these tests pass locally when ran isolated and in bulk from the test runner. On CircleCI.

Open to just thoughts on things I should try. Should I make some configuration adjustments in CircleCI that may help?

I don’t have any experience with FactoryBoy, but what is the full error message you’re getting? Curious if its complaining about some unique fields?

For the view tests, which database you’re using either local service, or over the network?

Also, I was confused about the last part.
Is there a consistent way to pass the tests on CircleCI?
Or are are the failures non-deterministic?

Best, Zak

@zzak

Thanks for getting back to me. So I’ve continued to stew over the issue and your comment on non-deterministic got me to thinking. And yes, the tests were running in a non-deterministic fashion and I’ve isolated the cause. Essentially FactoryBoy doesn’t gurantee unique_together – https://github.com/FactoryBoy/factory_boy/issues/241 nor does it really gurantee any since of uniqueness from Faker(). So one must be sensible in how they create these fixtures. With that said, a lesson was learned and think I’ve found a way forward. Thanks for weighing in, much appreciated.

1 Like

Glad to hear you were able to resolve this one @mgan59!

Thank you for your feedback :slight_smile: