Include sample settings file(s) to run django unit tests i.e. make running unit tests easier

[curtis@…]

Currently, running unit tests require a little bit of setup that in many cases (the most common case?) isn't needed. If sqlite3 is installed and no settings file is defined, this patch sets up a fake settings module with which to run the tests. In addition, it tries to use the version of django associated (checked out) with the tests and displays the path of the version being used.

This patch would allow someone to quickly checkout and run the tests for e.g.:

svn co http://code.djangoproject.com/svn/django/trunk/ django-trunk
curtis$ python django-trunk/tests/runtests.py

Running tests against /Users/curtis/Projects/django-trunk/django
----------------------------------------------------------------------
Ran 226 tests in 68.040s

OK

[Collin Grady <cgrady@…>]

That seems like a poor way to do it - couldn't you use settings.configure() instead of making a fake module?

[curtis@…]

Collin, thanks for the pointer. That's a much easier way to do it!

[curtis@…]

updated to use settings.configure()

[Russell Keith-Magee]

The implementation looks good, but I'm not convinced this is a good idea. Setting up a settings file isn't that difficult, and the ​documentation already describes the minimum requirements for a settings file.

Plus, as it stands, the requirement to provide a settings file to runtests.py serves as a mental reminder that you are only ever testing a single setup - other databases etc may yield different results. Giving runtests.py a 'default behaviour' suggests that there is a 'default configuration' which is all that needs to be tested. The runtests script is really for the benefit of developers, and it doesn't hurt to remind developers that anything they do for Django needs to be checked on multiple backends.

[Eric Holscher]

I talked with Jacob about this at EuroDjangoCon, and I think it would be a good idea. It really does allow people to get started running the test suite, and during things like sprints and such, that is a decently large time sink. I have a simple patch that allows you to do this, but if Russ thinks it shouldn't be included in core, then perhaps documenting how to get the test suite up and running would be a good solution as well.

[Russell Keith-Magee]

The process of setting up to run the test suite ​is already documented. I'm sure we can improve the presentation, but all the necessary information is already there.

I don't buy the 'time sink' argument - the settings file for SQLite requires exactly 1 line:

DATABASE_BACKEND='sqlite3'

Configuring for PosgreSQL/MySQL requires only 3 more lines, plus the overhead of creating a database instance. I find it hard to believe that this is the impediment slowing progress at a sprint, even if there are a lot of first-time contributors.

That said, I'm not mortally opposed to this idea. If the community really wants this, I'm willing to hold my nose and ignore the smell - ultimately, it doesn't have any real impact on my daily operation, since I have my suite of settings files already configured.

[Russell Keith-Magee]

Eric, Joseph and I have arrived at a compromise suggestion - checking in a test_sqlite.py settings file that is sufficient for testing sqlite, but still requires that you specify --settings=test_sqlite at the command line. Will commit soon.

[Tobias McNulty]

marking as Accepted per Russell

What about including sample test settings files for other databases as well? When ident authentication is enabled, postgres only needs one additional setting (the db name). e.g.:

DATABASE_ENGINE = 'postgresql_psycopg2'
DATABASE_NAME = 'django_unit_tests'

We could include the file without the DB name (and with the other empty settings) just to give people something to fill out, and emphasize the fact that it's good to run the tests with different DBs.

I tend to prefer 'test_sqlite.py.example' naming, which encourages folks to copy the file locally and modify it to fit their needs (without risking committing it back to SVN or including it in a patch by accident).

Thoughts?

[Tobias McNulty]

Oh, and the docs should probably updated as well. For lazy people (like myself) who only read the docs when they've tried it themselves first and then failed, it took awhile to figure out that you only need database settings in the settings file, not a full settings file. Given that the tests typically break if you do provide a full settings file, somehow making this more obvious might be a good thing.

I'll work on a patch hopefully later today

[Tobias McNulty]

<freakboy3742> tobias: Ok - the test_foo.py.example idea works for me.
<freakboy3742> As long as:
<freakboy3742> 1) It has a big set of instructions in the file "copy this, fill in these values, etc"
<freakboy3742> 2) Docs get updated (but keep the verbose versions)
<freakboy3742> (verbose instructions, that is)
<freakboy3742> 3) test_sqlite.py doesn't need to be an example - we can ship that one since it rely on passwords etc.

[Tobias McNulty]

assigning to kmtracey for review

[Karen Tracey]

Back to you for updates based on what all people were saying in IRC.

[Tobias McNulty]

just one example file, plus doc updates

[Tobias McNulty]

Here's a much smaller patch w/corresponding doc changes. Hopefully this is a good compromise b/t the original intent of this ticket (make it easier to test w/sqlite) and Jacob & Alex's wishes to do this entirely in documentation.

[Karen Tracey]

The mutlidb commit added a requirement that multiple databases be defined in order for the full Django test suite to pass. See: ​http://docs.djangoproject.com/en/dev/internals/contributing/#running-the-unit-tests. We're going to need to update the patch for this to account for that (and I think that makes a sample file even more needed. Whipping up a test settings file is no longer trivial). I'll get to it eventually but if anyone interested has free time before me feel free to update the patch.

[Rob Hudson]

Updated patch after multidb

[Eric Holscher]

Added docs to the settings file. Wrap docs.

[Eric Holscher]

Fix spacing in settings file.

[Eric Holscher]

Fix spacing in settings file.

[Jannis Leidel]

(In [12547]) Fixed #6298 - Added sample settings file to run the Django test suite (SQLite). Thanks, Eric Holscher.

[Jacob]

Milestone 1.2 deleted