[TIP] Naming Conventions for testing

Carl Meyer carl at oddbird.net
Mon Jul 25 13:19:55 PDT 2011

Hash: SHA1

Hi Alfredo,

On 07/25/2011 06:27 AM, Alfredo Deza wrote:
> I think I've always been in happy land when it comes to naming and other
> conventions for testing.
> Like prefacing your test files with "test" and placing them in a
> "test[s]" directory. There are slight 
> differences to that, like adding the test[s] module inside the actual
> package or not, which is still a rather
> acceptable difference.
> And I am completely OK with those slight differences.
> I am currently faced with a Django application that has tests in a
> `tests.py` file or a `tests` module that
> imports every test class that needs to be tested in `__init__.py`. I
> tried looking for test discovery and
> auto-discovery in the Django docs but came empty handed [0]

I think the historical reason for this is just that Django's test runner
was based on unittest, which had no support for discovery. Since Django
updated to unittest2, nobody has yet updated the test runner to make use
of discovery. I'm a Django committer and I'd like to see this change (I
hate the restriction that tests have to be directly in the 'tests'
module). I know at least some others feel similarly, though I don't
think there's been much public discussion yet so I don't know if some
might be opposed (can't think why, though). It just hasn't risen to the
top of anyone's priority list yet. Patches welcome, too :-)

> The reasoning for the above test structure is because Django's test
> runner will look for a tests module and 
> will run tests found there. If it is a directory, then only tests that
> are imported in `__init__.py` will be run.
> Again, no docs that I could find to support that (maybe this is a
> *custom* thing in this app?)

No, that's how the Django test runner works. It only looks for tests in
the "models" and "tests" modules of each app; if you make "tests" a
package rather than a one-file module, you have to import your tests
into __init__.py. I think the Django runner should be updated to do full
discovery within the "tests" package (if not within the entire app), or
at the very least have that as an option.

> My issue with this, is that it lends to have test files that are named
> `feature_foo.py` and not `test_foo.py`.
> Which it ends up breaking everything I've been used to until this moment. 

There's no real reason to make that leap (I still use the test_ prefix),
though I'm sure the lack of discovery does make it more likely that
people will skip the prefix, since it doesn't do anything.


> py.test, nose and I *think* that unittest2 have the same convention for
> autodiscovery.
> I am not complaining though, but my questions are: 
> * Am I wrong to have assumed we had a testing convention?
> * Is it just Django that does something like this? Or where are the docs
> that state otherwise?
> Feedback/input is greatly appreciated!
> -Alfredo
> [0] https://docs.djangoproject.com/search/?q=test+discovery&release=5
> <https://docs.djangoproject.com/search/?q=test+discovery&release=5>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the testing-in-python mailing list