On 05/09/2013 07:50 AM, Andrew Godwin wrote: > Just want to say that I'm happy with a "fast transition". > > Is there a possibility we can detect the case where the tests might be > broken (how might they be?) and print a helpful error message?
Two kinds of potential breakage: - The most common will be missing tests; doctests, or tests in files that don't match the test*.py pattern, which are currently run because they are in models.py or manually imported into a tests/__init__.py, won't be discovered by the new runner. Some people may also consider it a "breakage" that tests in their pip-installed external apps are no longer run by default. - Less common will be tests that are in the codebase for some reason (vendored third-party code, for instance?) that weren't found or run by the previous runner, but are found and run (and perhaps fail) with the new runner. The first kind of breakage I don't think we can reasonably discover at runtime; it would mean trying both discovery methods on every single test run and comparing test counts. We could do this in a special "upgrade check" like Russ suggested, but not every time you run tests. The second issue I'm not too concerned about. If the previously-undiscovered tests pass, then there's not really a problem. If they fail, it shouldn't be too hard to figure out what's going on. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
