Hey, sorry to respond to such an old thread, but now that 1.8 completely removed the old test runner, I am wondering if there's any way to get it back.
I don't want to explain why I want it back. Please don't tell me I don't want it. So, starting from the axiom that I want it back, how should I do it? Grab it from git history? On Tuesday, November 12, 2013 at 8:29:14 PM UTC-5, Russell Keith-Magee wrote: > > > On Sun, Nov 10, 2013 at 3:36 PM, Kyle MacFarlane <kylemac...@gmail.com > <javascript:>> wrote: > >> With the new test runner in 1.6 it only seems to be running tests under >> my project and ignoring all tests in dependent apps listed in >> INSTALLED_APPS. >> >> If I try to specify another app to test by doing something like "django >> test a_dependency" I get an exception from Python's unittest saying "Path >> must be within the project" (all my dependencies are installed system wide >> or in a shared buildout folder in my user dir). >> >> The only tests outside of my project I seem to be able to run are >> Django's itself via "django test django". >> >> How can I get the new test runner to discover and run all tests in >> INSTALLED_APPS? As far as I can tell the new test runner only supports >> tests located under the cwd which is not very useful for me since my >> projects tend to just amalgamate smaller apps located elsewhere. >> > > Hi Kyle, > > The short answer is no, you can't. However, there's method in this madness. > > Essentially *all* Django projects are amalgams of smaller apps from > elsewhere, so you're not alone in this. However, it doesn't follow that you > need to run the tests for those apps. Consider the tests for one of the > many apps in your project. This app is either: > > 1) A standalone, third party app, provided by another developer. This > developer has presumably written and run the test suite for that app, > validated that they pass, and packaged the app as version X. You pin > version X in your requirements file. At this point, there's no value in you > running these tests as part of your own project -- these tests aren't going > to start spontaneously failing just because they're in your project. > > 2) A standalone app that you're maintaining in house. Although you're > maintaining this in house, it's really no different to case 1. Good > discipline means writing code, running tests, and validating a release > (either as a tagged version, or just a VCS hash/revision) and pinning at > that release. Again, the testing of the app is (or should be) independent > of the testing of your project. > > 3) An app that is strongly tied to this particular project. In which case, > it should be part of the project directory, and will be picked up using > Django's test suite. If you want to put your project directory somewhere > other than the default, you can use the -t option to ./manage.py test to > point at your top level project directory. This doesn't change the > discovery strategy; it just alters the place that Django looks. > > So - you shouldn't have any need to run *all* the tests in INSTALLED_APPS > -- just the apps that are actually part of your project, and won't be > independently tested. If the app is independently maintained, but not > independently tested, you've got much bigger problems :-) > > Yours, > Russ Magee %-) > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/df0a8e3c-129e-4db4-8e8a-12d6d6ce7573%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
