Testing reusable application: compatible way

[Matwey V. Kornilov]

Hi,

I've followed this documentation: https://docs.djangoproject.com/en/1.7/topics/testing/advanced/#using-the-django-test-runner-to-test-reusable-applications
and found that it works only for Django 1.7, whereas I would like to have a code snipped working also for 1.5, 1.6.

An issue with the runtests.py from the link above that django.setup() has been introduced only in 1.7 and elder version seems to require different way to prepare settings object.

[Matwey V. Kornilov]

The following code works perfect for me, why the code in the documentations so sophisticated?

def runtests():
        os.environ.setdefault("DJANGO_SETTINGS_MODULE", "tests.test_settings")

        try:
                from django import setup
                setup()
        except ImportError:
                pass
        from django.core.management import call_command

        call_command("test","tests.__init__")

if __name__ == "__main__":
        runtests()


воскресенье, 7 декабря 2014 г., 18:40:42 UTC+3 пользователь Matwey V. Kornilov написал:

[Carl Meyer]

Hi Matwey,

On 12/07/2014 08:40 AM, Matwey V. Kornilov wrote:
> I've followed this documentation:
> https://docs.djangoproject.com/en/1.7/topics/testing/advanced/#using-the-django-test-runner-to-test-reusable-applications
> and found that it works only for Django 1.7, whereas I would like to
> have a code snipped working also for 1.5, 1.6.
>

> An issue with the runtests.py from the link above thatdjango.setup() has

> been introduced only in 1.7 and elder version seems to require different
> way to prepare settings object.

Older Django versions didn't require any explicit initialization step,
so all you need to do is check `hasattr(django, 'setup')` and only call
it if it exists (or you can check the Django version instead, if you
prefer).

DiscoverRunner was only introduced in 1.6, so if you want to be
1.5-compatible you'll also need a fallback to the old
DjangoTestSuiteRunner. And note that the format of test labels changed:
in DjangoTestSuiteRunner it was an app-label, where in DiscoverRunner
it's a full Python dotted path.

You can see an example `runtests.py` that accounts for these differences
here:
https://github.com/carljm/django-model-utils/blob/master/runtests.py#L34

Carl

[Carl Meyer]

On 12/07/2014 02:28 PM, Carl Meyer wrote:
> On 12/07/2014 08:40 AM, Matwey V. Kornilov wrote:
>> I've followed this documentation:
>> https://docs.djangoproject.com/en/1.7/topics/testing/advanced/#using-the-django-test-runner-to-test-reusable-applications
>> and found that it works only for Django 1.7, whereas I would like to
>> have a code snipped working also for 1.5, 1.6.
>>
>> An issue with the runtests.py from the link above thatdjango.setup() has
>> been introduced only in 1.7 and elder version seems to require different
>> way to prepare settings object.
>
> Older Django versions didn't require any explicit initialization step,
> so all you need to do is check `hasattr(django, 'setup')` and only call
> it if it exists (or you can check the Django version instead, if you
> prefer).
>
> DiscoverRunner was only introduced in 1.6, so if you want to be
> 1.5-compatible you'll also need a fallback to the old
> DjangoTestSuiteRunner. And note that the format of test labels changed:
> in DjangoTestSuiteRunner it was an app-label, where in DiscoverRunner
> it's a full Python dotted path.

I forgot that the documented example uses django.test.utils.get_runner
instead of directly importing DiscoverRunner. `get_runner` existed
already in 1.5, so that code should work back to 1.5, I would think.

[Carl Meyer]

On 12/07/2014 12:59 PM, Matwey V. Kornilov wrote:
> The following code works perfect for me, why the code in the
> documentations so sophisticated?
>
> def runtests():
> os.environ.setdefault("DJANGO_SETTINGS_MODULE",
> "tests.test_settings")
>
> try:
> from django import setup
> setup()
> except ImportError:
> pass
> from django.core.management import call_command
>
> call_command("test","tests.__init__")
>
> if __name__ == "__main__":
> runtests()

Sure, that works too. I don't think it's significantly simpler than the
documented version, and it's less flexible if you want to customize test
running further.

Carl