Issue #1277 resolved

Indistinguishable tests directories

Hynek Cernoch
created an issue

Tests for application keyedcache, livesettings, signals_ahoy and threaded_multihost are mixed together. Django can not reliably distinguish multiple directories of the same name placed on sys.path.

For example the directory ".../lib/python2.5/src/django-keyedcache/tests" overrides the directory ".../lib/python2.5/src/django-threaded-multihost/tests".

It is clear also from recommendations and Django source. Even no combination of PYTHONPATH and DJANGO_SETTINGS_MODULE (--pythonpath=... --settings=..) does not help.

How to verify:\ Add something to .../django-threaded-multihost/tests/model_tests/tests.py which should fail. cd .../django-threaded-multihost/tests ./manage.py test (ok) Rename ".../django-threaded-multihost/tests" to someting * The test fails now as it should.

Comments (5)

  1. Hynek Cernoch reporter

    Solution: Move "tests" to "threaded_multihost/test_app"

    cd src/django-threaded-multihost hg rename tests threaded_multihost/test_app

    Explain:
    Other three packages are not so important now, they have no own testcases. They only test very elementary that some Django tests would not be broken with them.

    Old directory "tests" are a small stub applications. They have not properties of Django tests directories which can be automatically searched for test cases. It is not enough to move one folder out of the path. Better is gradually giving the same new name ("test_app") to tests which are later fixed and moved off the path. I have some tips for important regression tests.

    Patch https://bitbucket.org/hynekcer/django-threaded-multihost/changeset/b4e414c93905

  2. Hynek Cernoch reporter
    • changed status to open

    The problem is now more important than it was when the issue was reported, for three reasons.

    • Sooner there were other bugs in many test more important than these.
    • I did not want to begin changes in many packages before I made some non-trivial improovments in these packages. Now is the time for fixing packages, which I have quite a well known.
    • I found a new circumstance, when fails are more serious:

    New problem

    Problem can be caused very easy by an upgrade of keyedcache and livesettings.

    The packages django-keyedcache, django-livesettings, django-signals-ahoy and django-threaded-multihost should be functional after have been installed in an arbitrary order, but the tests of keyedcache and livesettings do not work, if are installed after signals_ahoy.

    If the directory where is located directory signals_ahoy is searched before keyedcache and livesettings, then all Django management command in "django-livesettings/tests" or "django-threaded-multihost/tests" fail.

    It is if django-signals-ahoy for installations by "setup.py develop" or "pip install -e" or django_signals_ahoy-0.1_1-py2.5.egg for installations by "setup.py install" or "pip install" are listed before directories "django-livesettings" or "django-threaded-multihost" or "django_livesettings-1.4_9-py2.5.egg" or "django_threaded_multihost-1.4_1-py2.5" in the file "easy-install.pth".

    Example:
    go to arbitrary directory "tests" other then "django-signals-ahoy/tests", even some copy, which is not on the path.

    $ cd /home/.../site-packages/django_livesettings-1.4_9-py2.5.egg/tests
    $ python manage.py shell
    

    Error: No module named customapp

    Other exaple: [ issue #4 django-keyedcache] (Conequences of installing to shared site-settings are even worse.)

    Solutions:

    A) Moving the directory to an existing unique subdirectory and renaming it to something generic, but what does exists nowhere on the path. (e.g. move "tests" to "livesettings/tests")
    B) Renaming it to some globally unique name.

    I think, these solutions does not break any standard or well known functionality.

    Other solution does not exists, if the package should be installable by setuptools. Even playing with setup.py does not help entirely, becase it could fix only "setup.py install", not "setup.py develop".

  3. Log in to comment