Создание вашей первой Django-приложения, часть 5

Этот учебник начинается там, где Урок 4 закончился. Мы создали веб-приложение для опросов, и теперь мы создадим для него автоматические тесты.

Введение в автоматическое тестирование

Что такое автоматические тесты?

Тесты — это процедуры, которые проверяют работу вашего кода.

Тестирование выполняется на разных уровнях. Некоторые тесты могут относиться к мельчайшей детали (возвращает ли определенный метод модели ожидаемые значения?), в то время как другие проверяют общую работу программного обеспечения (последовательность действий пользователя на сайте приводит к желаемому результату?). Это ничем не отличается от типа тестирования, который вы выполняли ранее в Уроке 2, используя shell для проверки поведения метода или запуска приложения и ввода данных для проверки его поведения.

Разница в автоматических тестах заключается в том, что система выполняет работу по тестированию за вас. Вы создаёте набор тестов один раз, а затем, когда вносите изменения в своё приложение, можете проверить, работает ли ваш код так, как вы изначально предполагали, без необходимости проводить трудоёмкое ручное тестирование.

Зачем нужны тесты

Итак, зачем создавать тесты, и почему сейчас?

Вы можете чувствовать, что вам хватает обучения Python/Django, и добавление ещё одной задачи может показаться чрезмерным и, возможно, ненужным. В конце концов, наше приложение для опросов работает вполне хорошо; создание автоматических тестов не сделает его лучше. Если создание приложения для опросов — это последняя задача по программированию Django, которую вы когда-либо будете выполнять, то, да, вам не нужно знать, как создавать автоматические тесты. Но если это не так, сейчас отличное время для обучения.

Тесты сэкономят ваше время

До определённого момента проверка, «похоже, что работает», будет приемлемым тестом. В более сложном приложении у вас могут быть десятки сложных взаимодействий между компонентами.

Изменение любого из этих компонентов может иметь непредвиденные последствия для поведения приложения. Проверка того, что оно всё ещё «кажется работающим», может означать запуск функциональности вашего кода с двадцатью различными вариантами ваших тестовых данных, чтобы убедиться, что вы не сломали что-то — не лучшая трата вашего времени.

Это особенно верно, когда автоматические тесты могут сделать это за секунды. Если что-то пошло не так, тесты также помогут в определении кода, вызывающего неожиданное поведение.

Иногда может показаться утомительным отрываться от вашей продуктивной, творческой работы по программированию, чтобы столкнуться с непривлекательной и неинтересной задачей написания тестов, особенно когда вы знаете, что ваш код работает правильно.

Однако задача написания тестов гораздо более удовлетворительна, чем тратить часы на ручное тестирование вашего приложения или пытаться определить причину вновь возникшей проблемы.

Тесты не только выявляют проблемы, они предотвращают их

Ошибка думать о тестах только как о негативном аспекте разработки.

Без тестов назначение или предполагаемое поведение приложения может быть довольно неясным. Даже когда это ваш собственный код, вы иногда обнаруживаете себя копающимся в нём, пытаясь понять, что именно он делает.

Тесты изменяют это; они освещают ваш код изнутри, и когда что-то идёт не так, они фокусируют свет на части, которая пошла не так — даже если вы даже не осознавали, что что-то пошло не так.

Тесты делают ваш код более привлекательным

Вы могли создать блестящее программное обеспечение, но вы обнаружите, что многие другие разработчики откажутся от его рассмотрения из-за отсутствия тестов; без тестов они не будут ему доверять. Джейкоб Каплан-Мосс, один из первоначальных разработчиков Django, говорит: «Код без тестов по дизайну сломан».

То, что другие разработчики хотят видеть тесты в вашем программном обеспечении, прежде чем они его серьёзно воспримут, — ещё одна причина для вас начать писать тесты.

Тесты помогают командам работать вместе

Предыдущие пункты написаны с точки зрения одного разработчика, поддерживающего приложение. Сложные приложения будут поддерживаться командами. Тесты гарантируют, что коллеги не сломают ваш код непреднамеренно (и что вы не сломаете их без знания). Если вы хотите зарабатывать на жизнь программистом Django, вы должны уметь писать тесты!

Основные стратегии тестирования

Существует много способов подхода к написанию тестов.

Некоторые программисты придерживаются дисциплины под названием «разработка на основе тестирования»; они фактически пишут свои тесты перед тем, как писать свой код. Это может показаться нелогичным, но на самом деле это похоже на то, что большинство людей часто делают: они описывают проблему, а затем создают код для её решения. Разработка на основе тестирования формализует проблему в тестовом случае Python.

Чаще всего новичок в тестировании создаст код, а затем решит, что ему нужны тесты. Возможно, было бы лучше написать тесты раньше, но никогда не поздно начать.

Иногда трудно понять, с чего начать написание тестов. Если вы написали несколько тысяч строк Python, выбрать что-то для тестирования может быть непросто. В таком случае полезно написать свой первый тест в следующий раз, когда вы внесёте изменение, будь то добавление новой функции или исправление ошибки.

Итак, давайте сделаем это прямо сейчас.

Написание первого теста

Мы обнаруживаем ошибку

К счастью, в приложении polls есть небольшая ошибка, которую мы сразу же исправим: метод Question.was_published_recently() возвращает True, если Question был опубликован в течение последнего дня (что правильно), но также и если поле Question поля pub_date находится в будущем (чего, безусловно, не должно быть).

Подтвердите ошибку, используя shell для проверки метода на вопросе, дата которого находится в будущем:

$ python manage.py shell

...\> py manage.py shell

>>> import datetime
>>> from django.utils import timezone
>>> from polls.models import Question
>>> # create a Question instance with pub_date 30 days in the future
>>> future_question = Question(pub_date=timezone.now() + datetime.timedelta(days=30))
>>> # was it published recently?
>>> future_question.was_published_recently()
True

Поскольку события в будущем не являются «недавними», это явно неправильно.

Создайте тест для обнаружения ошибки

То, что мы только что сделали в shell для проверки проблемы, — это то, что мы можем сделать в автоматическом тесте, поэтому давайте превратим это в автоматический тест.

Конвенциональным местом для тестов приложения является файл tests.py приложения; система тестирования автоматически найдёт тесты в любом файле, имя которого начинается с test.

Вставьте следующее в файл tests.py в приложении polls:

import datetime

from django.test import TestCase
from django.utils import timezone

from .models import Question


class QuestionModelTests(TestCase):

    def test_was_published_recently_with_future_question(self):
        """
        was_published_recently() returns False for questions whose pub_date
        is in the future.
        """
        time = timezone.now() + datetime.timedelta(days=30)
        future_question = Question(pub_date=time)
        self.assertIs(future_question.was_published_recently(), False)

Здесь мы создали подкласс django.test.TestCase с методом, который создаёт экземпляр Question с pub_date в будущем. Затем мы проверяем результат was_published_recently() — который должен быть False.

Запуск тестов

В терминале мы можем запустить наш тест:

$ python manage.py test polls

...\> py manage.py test polls

и вы увидите что-то вроде:

Creating test database for alias 'default'...
System check identified no issues (0 silenced).
F
======================================================================
FAIL: test_was_published_recently_with_future_question (polls.tests.QuestionModelTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/path/to/mysite/polls/tests.py", line 16, in test_was_published_recently_with_future_question
    self.assertIs(future_question.was_published_recently(), False)
AssertionError: True is not False

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (failures=1)
Destroying test database for alias 'default'...

Вот что произошло:

• manage.py test polls искал тесты в приложении polls
• он нашёл подкласс класса django.test.TestCase
• он создал специальную базу данных для целей тестирования
• он искал тестовые методы — те, имена которых начинаются с test
• в test_was_published_recently_with_future_question он создал экземпляр Question, у которого поле pub_date находится на 30 дней в будущем
• … и используя метод assertIs(), он обнаружил, что его was_published_recently() возвращает True, хотя мы хотели, чтобы он возвращал False

Тест сообщает нам, какой тест не прошёл, и даже строку, на которой произошла неудача.

Исправление ошибки

Мы уже знаем, в чём проблема: Question.was_published_recently() должен возвращать False, если его pub_date находится в будущем. Измените метод в файле models.py, чтобы он возвращал True только если дата также находится в прошлом:

def was_published_recently(self):
    now = timezone.now()
    return now - datetime.timedelta(days=1) <= self.pub_date <= now

и снова запустите тест:

Creating test database for alias 'default'...
System check identified no issues (0 silenced).
.
----------------------------------------------------------------------
Ran 1 test in 0.001s

OK
Destroying test database for alias 'default'...

После обнаружения ошибки мы написали тест, который выявил её, и исправили ошибку в коде, так что наш тест прошёл.

В будущем могут возникнуть и другие проблемы с нашим приложением, но мы можем быть уверены, что непреднамеренно не вернём эту ошибку, потому что запуск теста немедленно предупредит нас. Мы можем считать эту небольшую часть приложения надёжно закреплённой навсегда.

Более всесторонние тесты

Пока мы здесь, мы можем дополнительно закрепить метод was_published_recently(); на самом деле, было бы крайне неудобно, если бы при исправлении одной ошибки мы ввели другую.

Добавьте еще два тестовых метода в тот же класс, чтобы более всесторонне протестировать поведение метода:

def test_was_published_recently_with_old_question(self):
    """
    was_published_recently() returns False for questions whose pub_date
    is older than 1 day.
    """
    time = timezone.now() - datetime.timedelta(days=1, seconds=1)
    old_question = Question(pub_date=time)
    self.assertIs(old_question.was_published_recently(), False)

def test_was_published_recently_with_recent_question(self):
    """
    was_published_recently() returns True for questions whose pub_date
    is within the last day.
    """
    time = timezone.now() - datetime.timedelta(hours=23, minutes=59, seconds=59)
    recent_question = Question(pub_date=time)
    self.assertIs(recent_question.was_published_recently(), True)

И теперь у нас есть три теста, подтверждающие, что Question.was_published_recently() возвращает осмысленные значения для вопросов прошлого, текущего и будущего.

Опять же, polls — это минимальное приложение, но вне зависимости от того, насколько сложным оно станет в будущем, и с какими другими кодами оно будет взаимодействовать, у нас теперь есть гарантия, что метод, для которого мы написали тесты, будет вести себя ожидаемым образом.

Тестирование представления

Приложение polls довольно нетребовательное: оно будет публиковать любой вопрос, включая те, у которых поле pub_date лежит в будущем. Мы должны это улучшить. Установка pub_date в будущем должна означать, что вопрос опубликован в этот момент, но невидим до этого момента.

Тест для представления

Когда мы исправили ошибку выше, мы сначала написали тест, а затем код для исправления. Фактически, это был пример разработки с тестированием, но в каком порядке мы выполним работу, не имеет значения.

В нашем первом тесте мы пристально сосредоточились на внутреннем поведении кода. В этом тесте мы хотим проверить его поведение с точки зрения пользователя через веб-браузер.

Прежде чем мы попытаемся что-либо исправить, давайте посмотрим на доступные инструменты.

Клиент Django для тестирования

Django предоставляет тестовый Client для моделирования взаимодействия пользователя с кодом на уровне представления. Мы можем использовать его в tests.py или даже в shell.

Мы начнём снова с shell, где нам нужно сделать несколько вещей, которые не понадобятся в tests.py. Первое — это настройка тестовой среды в shell:

$ python manage.py shell

...\> py manage.py shell

>>> from django.test.utils import setup_test_environment
>>> setup_test_environment()

setup_test_environment() устанавливает обработчик шаблонов, что позволит нам изучить дополнительные атрибуты в ответах, такие как response.context, которые иначе не были бы доступны. Обратите внимание, что этот метод не настраивает тестовую базу данных, поэтому следующее выполняется с существующей базой данных, и вывод может незначительно отличаться в зависимости от того, какие вопросы вы уже создали. Вы можете получить неожиданные результаты, если ваш TIME_ZONE в settings.py неверен. Если вы не помните, устанавливали ли вы его ранее, проверьте его перед продолжением.

Далее нам нужно импортировать класс тестового клиента (позже в tests.py мы будем использовать класс django.test.TestCase, который поставляется со своим собственным клиентом, поэтому это не потребуется):

>>> from django.test import Client
>>> # create an instance of the client for our use
>>> client = Client()

С этим готово, мы можем попросить клиента выполнить за нас работу:

>>> # get a response from '/'
>>> response = client.get('/')
Not Found: /
>>> # we should expect a 404 from that address; if you instead see an
>>> # "Invalid HTTP_HOST header" error and a 400 response, you probably
>>> # omitted the setup_test_environment() call described earlier.
>>> response.status_code
404
>>> # on the other hand we should expect to find something at '/polls/'
>>> # we'll use 'reverse()' rather than a hardcoded URL
>>> from django.urls import reverse
>>> response = client.get(reverse('polls:index'))
>>> response.status_code
200
>>> response.content
b'\n    <ul>\n    \n        <li><a href="/polls/1/">What&#x27;s up?</a></li>\n    \n    </ul>\n\n'
>>> response.context['latest_question_list']
<QuerySet [<Question: What's up?>]>

Улучшение представления

Список опросов показывает опросы, которые ещё не опубликованы (то есть те, у которых pub_date в будущем). Давайте исправим это.

В Учебнике 4 мы представили представление на основе класса, основанное на ListView:

class IndexView(generic.ListView):
    template_name = 'polls/index.html'
    context_object_name = 'latest_question_list'

    def get_queryset(self):
        """Return the last five published questions."""
        return Question.objects.order_by('-pub_date')[:5]

Нам нужно изменить метод get_queryset() и изменить его так, чтобы он также проверял дату, сравнивая её с timezone.now(). Сначала нам нужно добавить импорт:

from django.utils import timezone

а затем мы должны изменить метод get_queryset следующим образом:

def get_queryset(self):
    """
    Return the last five published questions (not including those set to be
    published in the future).
    """
    return Question.objects.filter(
        pub_date__lte=timezone.now()
    ).order_by('-pub_date')[:5]

Question.objects.filter(pub_date__lte=timezone.now()) возвращает набор запросов, содержащий Question, чьё pub_date меньше или равно — то есть, раньше или равно — timezone.now.

Тестирование нового представления

Теперь вы можете убедиться, что это работает как ожидается, запустив runserver, загрузив сайт в вашем браузере, создав Questions с датами прошлого и будущего и проверив, что перечислены только те, которые были опубликованы. Вам не нужно делать это каждый раз, когда вы вносите какое-либо изменение, которое может повлиять на это — поэтому давайте также создадим тест, основанный на нашей shell сессии выше.

Добавьте следующее в polls/tests.py:

from django.urls import reverse

и мы создадим функцию-обёртку для создания вопросов, а также новый класс тестов:

def create_question(question_text, days):
    """
    Create a question with the given `question_text` and published the
    given number of `days` offset to now (negative for questions published
    in the past, positive for questions that have yet to be published).
    """
    time = timezone.now() + datetime.timedelta(days=days)
    return Question.objects.create(question_text=question_text, pub_date=time)


class QuestionIndexViewTests(TestCase):
    def test_no_questions(self):
        """
        If no questions exist, an appropriate message is displayed.
        """
        response = self.client.get(reverse('polls:index'))
        self.assertEqual(response.status_code, 200)
        self.assertContains(response, "No polls are available.")
        self.assertQuerysetEqual(response.context['latest_question_list'], [])

    def test_past_question(self):
        """
        Questions with a pub_date in the past are displayed on the
        index page.
        """
        create_question(question_text="Past question.", days=-30)
        response = self.client.get(reverse('polls:index'))
        self.assertQuerysetEqual(
            response.context['latest_question_list'],
            ['<Question: Past question.>']
        )

    def test_future_question(self):
        """
        Questions with a pub_date in the future aren't displayed on
        the index page.
        """
        create_question(question_text="Future question.", days=30)
        response = self.client.get(reverse('polls:index'))
        self.assertContains(response, "No polls are available.")
        self.assertQuerysetEqual(response.context['latest_question_list'], [])

    def test_future_question_and_past_question(self):
        """
        Even if both past and future questions exist, only past questions
        are displayed.
        """
        create_question(question_text="Past question.", days=-30)
        create_question(question_text="Future question.", days=30)
        response = self.client.get(reverse('polls:index'))
        self.assertQuerysetEqual(
            response.context['latest_question_list'],
            ['<Question: Past question.>']
        )

    def test_two_past_questions(self):
        """
        The questions index page may display multiple questions.
        """
        create_question(question_text="Past question 1.", days=-30)
        create_question(question_text="Past question 2.", days=-5)
        response = self.client.get(reverse('polls:index'))
        self.assertQuerysetEqual(
            response.context['latest_question_list'],
            ['<Question: Past question 2.>', '<Question: Past question 1.>']
        )

Давайте рассмотрим некоторые из них поближе.

Во-первых, это функция-обёртка для создания вопросов, create_question, чтобы избавиться от повторений в процессе создания вопросов.

test_no_questions не создаёт никаких вопросов, но проверяет сообщение: «Доступны опросы» и проверяет, что latest_question_list пуст. Обратите внимание, что класс django.test.TestCase предоставляет дополнительные методы проверки. В этих примерах мы используем assertContains() и assertQuerysetEqual().

В test_past_question мы создаём вопрос и проверяем, что он появляется в списке.

В test_future_question мы создаём вопрос с pub_date в будущем. База данных сбрасывается для каждого тестового метода, поэтому первый вопрос больше не там, и поэтому в индексе больше не должно быть никаких вопросов.

И так далее. По сути, мы используем тесты, чтобы рассказать историю ввода администратора и пользовательского опыта на сайте и проверить, что на каждом этапе и для каждого нового изменения в состоянии системы публикуются ожидаемые результаты.

Тестирование представления DetailView

То, что у нас есть, работает хорошо; однако, хотя вопросы будущего не отображаются в списке, пользователи всё ещё могут получить доступ к ним, если знают или угадывают правильный URL. Поэтому нам нужно добавить подобное ограничение для DetailView:

class DetailView(generic.DetailView):
    ...
    def get_queryset(self):
        """
        Excludes any questions that aren't published yet.
        """
        return Question.objects.filter(pub_date__lte=timezone.now())

Затем мы должны добавить несколько тестов, чтобы проверить, что Question, чьё поле pub_date лежит в прошлом, можно отобразить, а тот, у которого pub_date в будущем, нельзя:

class QuestionDetailViewTests(TestCase):
    def test_future_question(self):
        """
        The detail view of a question with a pub_date in the future
        returns a 404 not found.
        """
        future_question = create_question(question_text='Future question.', days=5)
        url = reverse('polls:detail', args=(future_question.id,))
        response = self.client.get(url)
        self.assertEqual(response.status_code, 404)

    def test_past_question(self):
        """
        The detail view of a question with a pub_date in the past
        displays the question's text.
        """
        past_question = create_question(question_text='Past Question.', days=-5)
        url = reverse('polls:detail', args=(past_question.id,))
        response = self.client.get(url)
        self.assertContains(response, past_question.question_text)

Идеи для дополнительных тестов

Мы должны добавить аналогичный метод get_queryset в ResultsView и создать новый класс тестов для этого представления. Он будет очень похож на то, что мы только что создали; на самом деле будет много повторений.

Мы также могли бы улучшить наше приложение другими способами, добавляя тесты по ходу. Например, глупо, что Questions может быть опубликован на сайте, у которого нет Choices. Таким образом, наши представления могли бы проверить это и исключить такие Questions. Наши тесты создадут Question без Choices, а затем проверят, что он не опубликован, а также создадут подобное Question с Choices и проверят, что он опубликован.

Возможно, авторизованным пользователям-администраторам следует разрешить видеть неопубликованные Questions, но не обычным посетителям. Снова: всё, что нужно добавить в программное обеспечение для достижения этой цели, должно сопровождаться тестом, независимо от того, пишете ли вы тест сначала и затем заставляете код пройти тест, или сначала прорабатываете логику в вашем коде, а затем пишете тест, чтобы доказать его.

В какой-то момент вы неизбежно посмотрите на свои тесты и зададитесь вопросом, страдает ли ваш код от тестового надувания, что приводит нас к:

Когда больше тестирования — лучше

Может показаться, что наши тесты выходят из-под контроля. С такой скоростью вскоре в наших тестах будет больше кода, чем в нашем приложении, а повторы выглядят неэстетично по сравнению с изящной лаконичностью остального нашего кода.

Это не имеет значения. Пусть они растут. В большинстве случаев вы можете написать тест один раз и затем забыть о нём. Он будет продолжать выполнять свою полезную функцию по мере продолжения разработки вашей программы.

Иногда тесты придётся обновлять. Предположим, что мы изменим наши представления так, что будут опубликованы только Questions с Choices. В этом случае многие из наших существующих тестов потерпят неудачу — точно показывая, какие тесты нужно изменить, чтобы привести их в соответствие с последними данными, поэтому в этой степени тесты помогают следить за собой.

В худшем случае, по мере дальнейшей разработки, вы можете обнаружить, что некоторые тесты теперь излишни. Даже это не проблема; в тестировании избыточность — это хорошо.

Если ваши тесты разумно организованы, они не станут неконтролируемыми. К хорошим рекомендациям относятся:

• отдельный TestClass для каждой модели или представления
• отдельный тестовый метод для каждого набора условий, которые вы хотите проверить
• имена тестовых методов, описывающие их функцию

Дополнительное тестирование

В этом руководстве рассматриваются лишь основы тестирования. Существует гораздо больше возможностей и множество полезных инструментов для достижения более сложных целей.

Например, в то время как наши тесты охватывают внутреннюю логику модели и способ публикации информации представлениями, вы можете использовать фреймворк «в браузере», такой как Selenium, чтобы проверить, как ваш HTML отображается в браузере. Эти инструменты позволяют проверять не только поведение вашего кода Django, но и, например, ваш JavaScript. Довольно впечатляет наблюдать, как тесты запускают браузер и взаимодействуют с вашим сайтом так, как если бы это делал человек! Django включает LiveServerTestCase для облегчения интеграции с инструментами, подобными Selenium.

Если у вас сложная программа, вы можете захотеть автоматически запускать тесты при каждом коммите для целей непрерывной интеграции, чтобы контроль качества был, по крайней мере частично, автоматизирован.

Хороший способ обнаружить нетестированные части вашей программы — проверить покрытие кода. Это также помогает идентифицировать хрупкий или даже устаревший код. Если вы не можете протестировать часть кода, это обычно означает, что этот код следует переработать или удалить. Покрытие поможет идентифицировать устаревший код. Подробнее см. Интеграция с coverage.py.

Тестирование в Django содержит исчерпывающую информацию о тестировании.

Что дальше?

Для получения полной информации о тестировании см. Тестирование в Django.

Когда вы освоите тестирование представлений Django, прочитайте часть 6 этого руководства, чтобы узнать об управлении статическими файлами.