"python manage.py test" fails, but running the individual TestCase pass

[Dylan Yung]

There's some weird internal Django bug with views that use "transaction.atomic()" if you ping that view with multiple TestCase a weird bug will happen where there's a DB check at the end of tests after the DB has been torn down. I made 2 StackOverflow posts regarding this issue and found the fix as well. Hopefully there'll be an internal fix.

Because Django tests the db transaction processing mechanism, the real test part is finish and success, and then it will rollback the data（data flush),so some db level check is no use and misleading.

so we need modify the foreign key check defer to make it get right result.

​https://stackoverflow.com/questions/70105907/django-full-test-suite-failing-when-adding-a-testcase-but-full-test-suite-pas/70312267#70312267
​https://stackoverflow.com/questions/70166752/django-serializer-throwing-invalid-pk-object-does-not-exist-when-setting-m

I'm using a postgres DB

[Tim Graham]

It's not clear to me that Django is at fault. The accepted answer on Stackoverflow says, "There's some weird internal bug where if you operate on one table a lot with a lot of different TestCase classes then it'll do a DB check at the end after it's been torn down and it'll cause an error." but it's not clear that this is just speculation.

You need to at least provide a far simpler minimal example to reproduce the problem, and ideally, explain why Django is at fault. Thanks.