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

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

Представление автоматизированного тестирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы проверить, действительно ли существует ошибка, с помощью Администратора создайте вопрос, дата которого находится в будущем, и проверьте метод, используя 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.utils import timezone
from django.test import TestCase

from .models import Question


class QuestionMethodTests(TestCase):

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

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

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

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

$ python manage.py test polls

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

Creating test database for alias 'default'...
F
======================================================================
FAIL: test_was_published_recently_with_future_question (polls.tests.QuestionMethodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/path/to/mysite/polls/tests.py", line 16, in test_was_published_recently_with_future_question
    self.assertEqual(future_question.was_published_recently(), False)
AssertionError: True != False

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

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

Что произошло:

• python manage.py test polls искал тесты в приложении polls
• он нашёл подкласс класса django.test.TestCase
• он создал специальную базу данных для тестирования
• он искал тестовые методы — те, имена которых начинаются с test
• в test_was_published_recently_with_future_question он создал экземпляр Question с полем pub_date 30 дней в будущем
• ...и с помощью метода assertEqual() он обнаружил, что 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'...
.
----------------------------------------------------------------------
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() should return False for questions whose
    pub_date is older than 1 day.
    """
    time = timezone.now() - datetime.timedelta(days=30)
    old_question = Question(pub_date=time)
    self.assertEqual(old_question.was_published_recently(), False)

def test_was_published_recently_with_recent_question(self):
    """
    was_published_recently() should return True for questions whose
    pub_date is within the last day.
    """
    time = timezone.now() - datetime.timedelta(hours=1)
    recent_question = Question(pub_date=time)
    self.assertEqual(recent_question.was_published_recently(), True)

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

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

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

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

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

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

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

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

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

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

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

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

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

Далее нам нужно импортировать класс тестового клиента (позже в 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('/')
>>> # we should expect a 404 from that address
>>> 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.core.urlresolvers import reverse
>>> response = client.get(reverse('polls:index'))
>>> response.status_code
200
>>> response.content
b'\n\n\n    <p>No polls are available.</p>\n\n'
>>> # note - you might get unexpected results if your ``TIME_ZONE``
>>> # in ``settings.py`` is not correct. If you need to change it,
>>> # you will also need to restart your shell session
>>> from polls.models import Question
>>> from django.utils import timezone
>>> # create a Question and save it
>>> q = Question(question_text="Who is your favorite Beatle?", pub_date=timezone.now())
>>> q.save()
>>> # check the response once again
>>> response = client.get('/polls/')
>>> response.content
b'\n\n\n    <ul>\n    \n        <li><a href="/polls/1/">Who is your favorite Beatle?</a></li>\n    \n    </ul>\n\n'
>>> # If the following doesn't work, you probably omitted the call to
>>> # setup_test_environment() described above
>>> response.context['latest_question_list']
[<Question: Who is your favorite Beatle?>]

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

Список опросов показывает опросы, которые ещё не опубликованы (то есть те, у которых 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.core.urlresolvers import reverse

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

def create_question(question_text, days):
    """
    Creates 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 QuestionViewTests(TestCase):
    def test_index_view_with_no_questions(self):
        """
        If no questions exist, an appropriate message should be 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_index_view_with_a_past_question(self):
        """
        Questions with a pub_date in the past should be 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_index_view_with_a_future_question(self):
        """
        Questions with a pub_date in the future should not be 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_index_view_with_future_question_and_past_question(self):
        """
        Even if both past and future questions exist, only past questions
        should be 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_index_view_with_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_index_view_with_no_questions не создаёт никаких вопросов, но проверяет сообщение: «Нет доступных опросов» и проверяет, что latest_question_list пустой. Обратите внимание, что класс django.test.TestCase предоставляет дополнительные методы утверждения. В этих примерах мы используем assertContains() и assertQuerysetEqual().

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

В test_index_view_with_a_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 QuestionIndexDetailTests(TestCase):
    def test_detail_view_with_a_future_question(self):
        """
        The detail view of a question with a pub_date in the future should
        return 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_detail_view_with_a_past_question(self):
        """
        The detail view of a question with a pub_date in the past should
        display 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 этого учебника, чтобы узнать об управлении статическими файлами.