You may already know this, this is meant for others hitting this issue frankly.
In Django, you can count the number of queries in a unit test. You don't need 1M objects in the unit test, but maybe 30 in your case.
If the unit code uses more than X queries, then you should assume you have an N+1 bug. Like if you have 3 prefetch related and 2 select related's on 30 objects, but you end up with more than 30 queries, then you have an N+1 someplace.
Even better that unit test will protect you from hitting that error in the future in that chunk of code accessing that table.
I really want django-seal to be upstreamed, because accidental N+1's are really nasty and django-seal helps a lot with finding those
Isn't that going to be super annoying when doing interactive work or when you really can't avoid it?
And sometimes not so obvious, I have been bitten by forgetting one select_related while inadvertedly joining 5 tables but using only 4 select_related: the tests work OK, but the real data has a number of records that cause a N+1. A request that used to take 100ms now issues "30 seconds timeout" from time to time.
Once we added the missing select_related we went back to sub-second request, but it was very easy to start blaming Django itself because the number of records to join was getting high.
The cases that we usually walk out of the Django path is for serializations and representations, trying to avoid the creation of intermediate objects when we only need the "values()" return.