On Thu, Jul 4, 2013 at 8:42 PM, Larry Martell <[email protected]> wrote: > > I'm just getting involved with setting up testing using the django > testing facilities, and I have a couple of questions. > > If I do this from the django shell: > > $ python manage.py shell > Python 2.7.2 (default, Oct 11 2012, 20:14:37) > [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on > darwin > Type "help", "copyright", "credits" or "license" for more information. > (InteractiveConsole) > >>> from django.test.utils import setup_test_environment > >>> setup_test_environment() > >>> > > Should I expect to see that the test db was created? Because I do not > see it. (The docs say "This convenience method sets up the test > database").
It seems you are using Django <= 1.4. the docs were wrong n these versions. setup_test_environment() doesn't actually creates the test DB. That section of the docs were [1]updated in >= 1.5 to point to the .setup_databases() method the relevant TestRunner class which is the one in charge of the DB creation. > But then I read: > > create_test_db: Creates a new test database and runs syncdb against > it. So then I thought maybe I have to call that. But I got: > > >>> create_test_db() > Traceback (most recent call last): > File "<console>", line 1, in <module> > NameError: name 'create_test_db' is not defined > That create_test_db() is a low-level DB backend method that provides the low-level support to this functionality. Its easy to miss but thee is a "The creation module of the database backend (connection.creation) also provides some utilities that can be useful during testing." paragraph above its description. > > Concerning fixture, I read in the docs where it says you can set up > fixture files for initialing the test db. What will prevent those test > fixtures from getting loaded when I do a syncdb of my 'real' database? Documentation is clear in this case: - The only DB fixtures leaded automatically on syncdb are the ones named 'initial_data' - You should explicitly specify the names of the DB fixtures you want loaded for a given test case. So there are two safety nets there. You need to break them explicitly to get to that potentially disastrous scenario. -- Ramiro Morales @ramiromorales 1. https://docs.djangoproject.com/en/1.5/topics/testing/advanced/#running-tests-outside-the-test-runner -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users. For more options, visit https://groups.google.com/groups/opt_out.
