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.

Reply via email to