Various factors creating an unparsable rerun log

[stevejalim]

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]

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]

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]

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]

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.