search

yunojuno / django-juno-testrunner

A more useful (and slightly more glamorous) test runner for Django 1.6+ from the folks at YunoJuno
MIT License
7 stars 9 forks source link

Various factors creating an unparsable rerun log #1

Open stevejalim opened 10 years ago

stevejalim commented 10 years ago

If the test run is killed mid-way, there's a risk of an incomplete test path being written to the log, which then causes an import error.

Separately, there are some (still unconfirmed) circumstances where a tests fails (quite possibly due to an import error) which then is handled poorly and a class from unittest is added to the rerun log. This, naturally, will cause the rerun log to fail.

hugorodgerbrown commented 10 years ago

Steve - this may be totally unrelated, but every now and then I get an import error somewhere, and a unittest reference ends up in rerun.txt (don't have the exact details), which then borks on the rerun?

stevejalim commented 10 years ago

Ah, interesting. I know what that is: usually when a test is removed, say, and the whole TestCase is missing when rerun tries to run it (or there's an import error in the test which means the test is not discovered).

Will make sure that those references are not added to rerun log

[ ] Ensure that only full qualified test names, not test classes, can be added to rerun log

stevejalim commented 9 years ago

As an example of a borked test leading to a unititest class name ending up in the rerun log:

unittest.loader.ModuleImportFailure.yunojuno.apps.profiles.tests.selenium_tests.test_briefs
unittest.loader.ModuleImportFailure.yunojuno.apps.profiles.tests.selenium_tests.test_example
gergelypolonkai commented 8 years ago

For this I have a workaround in my project’s Makefile:

sed -i 's/^unittest.loader.ModuleImportFailure.//' test_rerun.txt

Not too beautiful, but it works. I’m not sure if this should be solved on django-juno-testrunner’s side, as it seems to be a general problem for all runners.