Hey Tobias, thanks for chiming in. The main motivation behind this package and this core inclusion proposal is that I've come across a non-negligible number users that were surprised to find out this was not working automatically and others that completely stopped using setUpTestData because of this limitation (we're even doing this in the Django test suite under certain circumstances). Now these cases could effectively be solved by an explicit decoration of the setUpTestData method but it does feel like an hack, at least to me, that users shouldn't have to worry about given how TestCase was branded as a bulletproof test data isolation tool.
With that said I wouldn't really mind forcing the developer to opt-in through the use of a decorator like in the external package does if that's what the consensus is here. I just wanted to mention that I was having a hard time siding with the _too much magic_ argument given all the isolation _magic_ TestCase already performs. Cheers, Simon Le dimanche 2 décembre 2018 19:43:14 UTC-5, Tobias McNulty a écrit : > > On Fri, Nov 30, 2018, 1:03 PM Adam Johnson <m...@adamj.eu <javascript:> > wrote: > >> Tobias - using database updates isn't always viable. Also the system >> under test might need to take in the model instance, mutate it and execute >> its own save(), and then there's no way of rolling that back if the object >> wasn't deepcopy'd >> > > Fair enough, but for those cases, one could just as easily deepcopy the > object in the test itself. Again, it's more explicit, gives the developer > control over exactly what they want to happen, and makes failures more > obvious. > > I suppose if the API allowed one to mix and match approaches for different > tests and model objects (like Simon's testdata app does right now), that > would work, too. > > Tobias > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4881f375-5966-4f09-905a-ef807df129fa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
