Написание вашего первого приложения Django, часть 5

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

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

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

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

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

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

Зачем вам создавать тесты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы выявляем ошибку

К счастью, в приложении polls есть небольшая ошибка, которую нужно исправить: метод Question.was_published_recently() возвращает True, если вопрос был опубликован в течение последнего дня (что верно), но также и если поле 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.
        """
        question = create_question(question_text="Past question.", days=-30)
        response = self.client.get(reverse('polls:index'))
        self.assertQuerysetEqual(
            response.context['latest_question_list'],
            [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.
        """
        question = 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],
        )

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

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

Первая — это функция-короткая запись вопроса, create_question, чтобы избежать повторения при создании вопросов.

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

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

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

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

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

Все работает хорошо; однако, хотя вопросы будущего не отображаются в списке, пользователи все равно могут получить к ним доступ, если знают или предполагают правильный 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 этого учебника, чтобы узнать о управлении статическими файлами.