Unified listing of shell commands/code

.. code-block:: bash

   pip install -U Django

   $ pip install -U Django

pip_ also automatically uninstalls the previous version of Django.

.. code-block:: bash

    git clone git@github.com:django/django.git django-repo

    cd django-repo/tests

    PYTHONPATH=..:$PYTHONPATH ./runtests.py

   $ git clone git@github.com:django/django.git django-repo

   $ cd django-repo/tests

   $ PYTHONPATH=..:$PYTHONPATH ./runtests.py

.. versionchanged:: 1.7

Older versions of Django required specifying a settings file::

Older versions of Django required specifying a settings file:

    PYTHONPATH=..:$PYTHONPATH python ./runtests.py --settings=test_sqlite

.. code-block:: bash

   $ PYTHONPATH=..:$PYTHONPATH python ./runtests.py --settings=test_sqlite

``runtests.py`` now uses ``test_sqlite`` by default if settings aren't provided

through either ``--settings`` or :envvar:`DJANGO_SETTINGS_MODULE`.

.. code-block:: bash

    ./runtests.py --settings=path.to.settings generic_relations i18n

   $ ./runtests.py --settings=path.to.settings generic_relations i18n

How do you find out the names of individual tests? Look in ``tests/`` — each

directory name there is the name of a test. Contrib app names are also valid

.. code-block:: bash

    ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests

   $ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests

Going beyond that, you can specify an individual test method like this:

.. code-block:: bash

    ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects

   $ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects

Running the Selenium tests

~~~~~~~~~~~~~~~~~~~~~~~~~~

.. code-block:: bash

    ./runtests.py --settings=test_sqlite --selenium admin_inlines

   $ ./runtests.py --settings=test_sqlite --selenium admin_inlines

.. _running-unit-tests-dependencies:

You can find these dependencies in `pip requirements files`_ inside the

``tests/requirements`` directory of the Django source tree and install them

like so::

like so:

    pip install -r tests/requirements/py2.txt  # Python 3: py3.txt

.. code-block:: bash

   $ pip install -r tests/requirements/py2.txt  # Python 3: py3.txt

You can also install the database adapter(s) of your choice using

``oracle.txt``, ``mysql.txt``, or ``postgres.txt``.

that need additional tests. The coverage tool installation and use is described

in :ref:`testing code coverage<topics-testing-code-coverage>`.

To run coverage on the Django test suite using the standard test settings::

To run coverage on the Django test suite using the standard test settings:

.. code-block:: bash

   $ coverage run ./runtests.py --settings=test_sqlite

    coverage run ./runtests.py --settings=test_sqlite

After running coverage, generate the html report by running:

After running coverage, generate the html report by running::

.. code-block:: bash

    coverage html

   $ coverage html

When running coverage for the Django tests, the included ``.coveragerc``

settings file  defines ``coverage_html`` as the output directory for the report

If you have URLs that need to be mapped, put them in ``tests/urls.py``.

To run tests for just one contrib app (e.g. ``auth``), use the same

method as above::

method as above:

.. code-block:: bash

    ./runtests.py --settings=settings django.contrib.auth

   $ ./runtests.py --settings=settings django.contrib.auth

.. code-block:: bash

    python -c "import django; print(django.get_version())"

    $ python -c "import django; print(django.get_version())"

If Django is installed, you should see the version of your installation. If it

isn't, you'll get an error telling "No module named django".

.. code-block:: bash

   django-admin.py startproject mysite

   $ django-admin.py startproject mysite

This will create a ``mysite`` directory in your current directory. If it didn't

work, see :ref:`troubleshooting-django-admin-py`.

----------------------

Let's verify this worked. Change into the outer :file:`mysite` directory, if

you haven't already, and run the command ``python manage.py runserver``. You'll

see the following output on the command line:

you haven't already, and run the command:

.. code-block:: bash

   $ python manage.py runserver

You'll see the following output on the command line:

.. parsed-literal::

losing data. We'll cover them in more depth in a later part of the tutorial,

but for now, remember the three-step guide to making model changes:

* Change your models (in models.py)

* Run ``python manage.py makemigrations`` to create migrations for those changes

* Run ``python manage.py migrate`` to apply those changes to the database.

* Change your models (in ``models.py``).

* Run :djadmin:`python manage.py makemigrations <makemigrations>` to create

  migrations for those changes

* Run :djadmin:`python manage.py migrate <migrate>` to apply those changes to

  the database.

The reason there's separate commands to make and apply migrations is because

you'll commit migrations to your version control system and ship them with

    .. code-block:: bash

        python -c "

        $ python -c "

        import sys

        sys.path = sys.path[1:]

        import django

.. code-block:: bash

    django-admin.py <command> [options]

    manage.py <command> [options]

    $ django-admin.py <command> [options]

    $ manage.py <command> [options]

``command`` should be one of the commands listed in this document.

``options``, which is optional, should be zero or more of the options available