Adam: I don't think they should be optional, or if they are, they should be
opt-out. The checks are a brilliant guard against error, but not running
them as part of test invites them not being run at all in a TDD workflow,
as often code can be developed with nothing but running the tests. It is
also surprising that *only* test doesn't run them, since every other manage
command
does.
I agree with this. I don't see why an opt-out option is not valid?
Dne torek, 20. oktober 2015 02.48.29 UTC+2 je oseba Tim Graham napisala:
>
> A ticket [1] and pull request [2] note that `manage.py test` ran the
> system checks in Django 1.7 (as a side effect of call_command('migrate')),
> but this is no longer the case in Django 1.8 since call_command() doesn't
> trigger the system checks anymore.
>
> me: I'm of the opinion that running the system checks as part of the
> manage.py
> test command should be opt-in (for example, by writing a test that
> asserts the call_command('check') output is empty. For example, when
> debugging a single test, it doesn't seem necessary to have the overhead of
> running check. As more options are added to check (e.g. #25500
> <https://code.djangoproject.com/ticket/25500>), a default implementation
> as currently proposed could become increasing inflexible. I'd like to
> document the change in the 1.8 release notes and suggest the alternative.
>
>
> Adam: I don't think they should be optional, or if they are, they should
> be opt-out. The checks are a brilliant guard against error, but not running
> them as part of test invites them not being run at all in a TDD workflow,
> as often code can be developed with nothing but running the tests. It is
> also surprising that *only* test doesn't run them, since every other
> manage command does.
> At YPlan we couldn't do without them as part of tests. Our aforementioned
> 'installed packages' check saves a lot of time that would otherwise be
> wasted understanding confusing error messages about imports not working,
> and our other custom checks do verification similar to Django's, for issues
> that without resolution it does not make sense to even attempt do any
> tests. Also we don't notice any real overhead, we can still get a single
> test to run in 1 second (with --keepdb :) ) despite all our extra messing
> around with pip freeze etc.
>
> Other opinions?
>
> [1] https://code.djangoproject.com/ticket/25415
> [2] https://github.com/django/django/pull/5293
>
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/2ef0f6de-4f1c-4067-8154-b56ff11025d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
