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

Что такое автоматизированные тесты? ¶

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

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

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

Зачем нужно создавать тесты ¶

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

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

Обнаружена ошибка ¶

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

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

$ python manage.py shell

... \> оболочка py manage.py

>>> 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

и вы должны увидеть что-то вроде:

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 ;
• in test_was_published_recently_with_future_question она создала экземпляр Question , поле которого pub_date находится на 30 днях в будущем;
• ... и, используя метод assertIs() , она обнаружила, что ее метод was_published_recently() возвращается True , тогда как мы хотели, чтобы он вернулся False .

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

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

Мы уже знаем проблему: Question.was_published_recently() следует отправить повторно, False если она появится pub_date в будущем. Исправьте метод in, 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 это минимальное приложение, но независимо от того, насколько сложным оно будет развиваться или с каким кодом оно будет взаимодействовать, теперь у нас есть некоторая гарантия того, что метод, для которого мы написали тесты, будет вести себя согласованно.

Тест на вид ¶

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

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

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

Тестовый клиент Django ¶

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

Мы начнем снова с shell , где нам нужно выполнить некоторые операции, которые не понадобятся tests.py . Первый - настроить тестовую среду в shell :

$ python manage.py shell

... \> оболочка py manage.py

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

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

Затем необходимо импортировать тестовый класс Client (позже 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()) возвращает набор запросов, содержащий вопросы, поле pub_date которых меньше или равно (то есть старше или равно) timezone.now .

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

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

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

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

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