Thanks Russ I'll try what you suggested, I was hoping there was another way besides how I was trying to do it.
Many people compare Django to rails which, independent of any other connotations, does seem to expose a difference in testing. It's been almost a year since I worked with rails, and the biggest difference so far is testing. My "second class" citizen comment was partly because rails creates a test-specific directory from the start, and has so many testing tools and frameworks. Python has a large selection of testing frameworks too, (now including google's open sourced pymox http://code.google.com/p/pymox/). For many developers, myself included, developer testing is very important. And some friends of mine choose a non-django framework in the past on the exclusive basis of testing. Now, with 0.96 and head this is getting *much* better. (For me Testing is #1, Tools support is #2, and Developer productivity is #3.) I'm enjoying exploring Django so far, and hope to find more about the state of testing. Thanks On Jul 13, 7:45 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 9:28 AM, jawspeak <[EMAIL PROTECTED]> wrote: > > > I'm not experienced in python but coming from Java I'm having a hard > > time being forced to put all my tests for an app in one file. > ... > > It really bothers me that I don't know how to automatically include > > every file under my tests directory, to run automatically. What's the > > right way to create a suite? > > I don't think your statement that testing has 'second class' status is > accurate. Django contains a testing module; that testing module > contains some default behaviours and assumptions. Those defaults are > not useful for every project, so you will sometimes need to step > outside the defaults. That doesn't mean testing has second-class > status - just that the defaults don't suit your application. > > You have discovered one way to work around the defaults: import the > unit tests you need into tests/__init__.py. However, there are at > least 2 other options: > > Firstly, you can define a suite() function in tests.py (or models.py). > This approach is documented as part of the Python unittest framework > [1]. That suite function can use whatever discovery approach you find > helpful. > > Secondly, you can override Django's test discovery behaviour. You do > this by writing a custom test runner [2] that employs a different > approach to finding and building the test suite. The default test > runner can be found in django.test.simple. This method is fairly > straight forward; writing a replacement isn't a difficult task. > > Of course, we are always open to suggestions for how to make the > defaults more useful. If you have a suggestion for a better set of > default behaviours, feel free to make the suggestion. However, keep in > mind that your suggestion needs to be appropriate for _every_ Django > project - not just your project. > > [1]http://docs.python.org/lib/organizing-tests.html > [2]http://www.djangoproject.com/documentation/testing/#defining-a-test-r... > > Yours > Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
