C юнит тесты: Unit-тесты на C# — Разработка на vc.ru

Unit-тесты в Python | by Nick Komissarenko

B прошлой статье мы рассказывали о организации модулей Python, особенно полезных для крупных Data Science проектов. В этот раз поговорим о модульном тестировании (unit testing): читайте в нашей статье о том, как писать и запускать тесты для проверок функций и как в стандартной библиотеке Python применяется один из главных принципов разработки ПО — DRY (don’t repeat yourself).

Пишем простые тесты для функций модуля

Для тестирования будем использовать стандартную библиотеку unittest. Допустим, имеется Python-файл с двумя функциями:

# файл calc.py

def add(x, y):

return x + y

def is_positive(x):

return x > 0

Требуется написать тесты для этого файла (модуля), который проверит правильность разработанных функций. Для этого создадим файл tests.py, в котором будет класс с методом для тестирования. Важно, чтобы все методы с тестами начинались с test_, иначе Python не поймет, что тестировать. После наследования от класса TestCase из unittest будут доступны методы, которые проверяют на соответствие ожидаемому результату. Напишем несколько проверок для функций вышеприведённого модуля:

# файл tests.py

import unittest
import calc

class TestCalc(unittest.TestCase):
def test_add(self):
self.assertEqual(calc.add(3, 6), 9)

def test_is_positive(self):
self.assertTrue(calc.is_positive(0))

Здесь два теста: один проверяет на равенство, другой на истину. Кроме того, имеются и другие виды проверок, которые показаны на рисунке ниже. Так, например, для сравнений чисел с плавающей точкой (float) рекомендуется использовать assertAlomstEqual.

Список методов для проверки на ожидаемое соответствие Запуск unit-тестов

Для запуска тестов нужно написать в командой строке следующее:

$ python -m unittest tests.py

На экране выведется сообщение о проведении тестов и их статус. Каждый пройденный тест обозначается точкой ., а проваленной буквой F. В нашем случае получили две точки и статус ОК:

..

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Ran 2 tests in 0. 000s

OK

Кроме того, чтобы не прописывать всю вышеприведённую строчку, можно добавить в Python-файл с тестами вызов функции unittest.main в конце в блоке __main__, о котором говорили тут:

if __name__ == ‘__main__’:
unittest.main()

Тогда запуск осуществляется простой командой:

$ python tests.py

Проваленные тесты

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

def test_is_positive(self): self.assertTrue(calc.is_positive(-1))

Ниже показано сообщение. В результате мы провалили один тест и получили .F и статус Failed.

.F

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

FF

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

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

# Файл calc.py

def divide(x, y):
if y == 0:
raise ZeroDivisionError
return x / y

Тогда для проверки исключений рекомендуется использовать контекстный менеджер Python, внутри которого просто вызвать проверяемую функцию:

def test_divide(self):
self.assertEqual(calc.divide(10, 2), 5)
with self.assertRaises(ZeroDivisionError) as cm:
calc.divide(10, 0)

Операции перед проведением тестов

Порой требуется выполнить операции перед каждым тестом, особенно, если требуется протестировать методы класса, не создавая постоянно экземпляров класса. Более того, это позволит соблюсти принцип DRY (Don’t Repeat Youreself — не повторяйся). Пусть в файле person.py имеется класс Person, который хранит информацию о имени, фамилии и e-mail:

class Person:
def __init__(self, first_name, last_name):
self. first = first_name
self.last = last_name

@property
def email(self):
return f”{self.last}@school.ru”

@property
def full(self):
return f”{self.first} {self.last}”

Воспользуемся методом setUp, который перед каждым тестом будет создавать экземпляр класса Person. В итоге, проверим правильность введенного e-mail и полного имени. Ниже приведён код на Python.

class TestPerson(unittest.TestCase):
@classmethod
def setUpClass(cls):
cls.p = Person(“Vasya”, “Frolov”)

def test_email(self):
self.assertEqual(self.p.email, “[email protected]”)

def test_fullname(self):
self.assertEqual(self.p.full, “Vasya Frolov”)

Помимо setUp, имеется метод tearDown, который, наоборот, запускается в конце каждого теста. Эти методы также пригодятся для открытия и закрытия файлов.

В следующей статье поговорим о продвинутых темах модульного тестирования. А о том, как писать тесты в реальных проектах Data Science, вы узнаете на наших Python-курсах в лицензированном учебном центре обучения и повышения квалификации IT-специалистов в Москве.

Смотреть расписание

Руководство часть 10: Тестирование приложений Django — Изучение веб-разработки

Сайты, в процессе развития и разработки, становится все сложнее тестировать вручную. Кроме такого тестирования, сложными становятся внутренние взаимодействия между компонентами — внесение небольшого изменения в одной части приложения влияет на другие. При этом, чтобы все продолжало работать нужно вносить все больше и больше изменений и, желательно так, чтобы не добавлялись новые ошибки. Одним из способов который позволяет смягчить последствия добавления изменений, является внедрение в разработку автоматического тестирования — оно должно просто и надежно запускаться каждый раз, когда вы вносите изменения в свой код. Данное руководство рассматривает вопросы автоматизации юнит-тестирования вашего сайта при помощи фреймворка Django для тестов.

LocalLibrary в настоящий момент содержит страницы для показа списков всех книг, авторов, подробной информации о книгах Book и авторах Author, а также страницу для обновления информации об экземпляре книги BookInstance и, кроме того, страницы для создания, обновления и удаления записей модели Author (и модели Book, в том случае, если вы выполнили домашнее задание в руководстве работа с формами). Даже в случае небольшого сайта, ручной переход на каждую страницу и беглая проверка того, что все работает как следует, может занять несколько минут. В процессе внесения изменений и роста сайта требуемое время для проведения проверок будет только возрастать. Если бы мы продолжили в том же духе, то в какой-то момент на проведение тестов мы тратили бы больше времени, чем на написание кода и внесение изменений.

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

Кроме того, автоматические тесты могут действовать как первый «настоящий пользователь» вашего кода, заставляя вас строго следить за объявлениями и документированием поведения вашего сайта. Тесты часто являются основой для создания примеров вашего кода и документации. По этим причинам иногда некоторые процессы разработки программного обеспечения начинаются с определения тестов и их реализации, а уже после этого следует написание кода который должен иметь соответствующее поведение (так называемая разработка на основе тестов и на основе поведения).

Данное руководство показывает процесс создания автоматических тестов в Django при помощи добавления их к разработке сайта LocalLibrary.

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

Существует несколько типов, уровней, классификаций тестов и тестовых приемов. Наиболее важными автоматическими тестами являются:

Юнит-тесты

Проверяют функциональное поведение для отдельных компонентов, часто классов и функций.

Регрессионное тестирование

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

Интеграционные тесты

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

Примечание:  К другим типам тестов относятся методы чёрного ящика, белого ящика, ручные, автоматические, канареечные (canary), дымные (smoke), соответствия (conformance), принятия (acceptance), функциональные (functional),  системные (system), эффективности (performance), загрузочные (load) и стресс-тесты (stress tests).

Что Django предоставляет для тестирования?

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

Django предоставляет фреймворк для создания тестов, построенного на основе иерархии классов, которые, в свою очередь, зависят от стандартной библиотеки Python  unittest. Несмотря на название, данный фреймворк подходит и для юнит-, и для интеграционного тестирования. Фреймворк Django добавляет методы API и инструменты, которые помогают тестировать как веб так и, специфическое для Django, поведение. Это позволяет вам имитировать URL-запросы, добавление тестовых данных, а также проводить проверку выходных данных ваших приложений. Кроме того, Django предоставляет API (LiveServerTestCase) и инструменты для применения различных фреймфорков тестирования, например вы можете подключить популярный фреймворк Selenium для имитации поведения пользователя в реальном браузере.

Для написания теста вы должны наследоваться от любого из классов тестирования Django (или юниттеста)  (SimpleTestCase, TransactionTestCase, TestCase, LiveServerTestCase), а затем реализовать отдельные методы проверки кода (тесты это функции-«утверждения», которые проверяют, что результатом выражения являются значения True или False, или что два значения равны и так далее). Когда вы запускаете тест, фреймворк выполняет соответствующие тестовые методы в вашем классе-наследнике. Методы тестирования запускаются независимо друг от друга, начиная с метода настроек и/или завершаясь методом разрушения (tear-down), определенном в классе, как показано ниже.

class YourTestClass(TestCase):

    def setUp(self):
        
        pass

    def tearDown(self):
        
        pass

    def test_something_that_will_pass(self):
        self.assertFalse(False)

    def test_something_that_will_fail(self):
        self.assertTrue(False)

Самый подходящий базовый класс для большинства тестов это django.test.TestCase.  Этот класс создает чистую базу данных перед запуском своих методов, а также запускает каждую функцию тестирования в его собственной транзакции. У данного класса также имеется тестовый Клиент, который вы можете использовать для имитации взаимодействия пользователя с кодом на уровне отображения. В следующих разделах мы сконцентритуемся на юнит-тестах, которые будут созданы на основе класса TestCase.

Примечание: Класс django.test.TestCase очень удобен, но он может приводить к замедленной работе в некоторых случаях (не для каждого теста необходимо настраивать базу данных, или имитировать взаимодействие с отображеним). Когда вы познакомитесь с работой данного класса, то сможете заменить некоторые из ваших тестов на более простые классы тестирования.

Что вы должны тестировать?

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

Например, рассмотрим модель Author, определенную ниже. Вам не нужно проверять тот факт, что first_name и last_name были сохранены в базу данных как CharField, потому что за это отвечает непосредственно Django (хотя конечно, на практике  в течение разработки вы косвенно будете проверять данную функциональность). Тоже касается и, например, проверки того, что поле date_of_birth является датой, поскольку это тоже часть реализации Django.

Вы должны проверить текст для меток (First name, Last_name, Date of birth, Died), и размер поля, выделенного для текста (100 символов), потому что они являются частью вашей разработки и чем-то, что может сломаться/измениться в будущем.

class Author(models.Model):
    first_name = models.CharField(max_length=100)
    last_name = models.CharField(max_length=100)
    date_of_birth = models.DateField(null=True, blank=True)
    date_of_death = models.DateField('Died', null=True, blank=True)

    def get_absolute_url(self):
        return reverse('author-detail', args=[str(self.id)])

    def __str__(self):
        return '%s, %s' % (self.last_name, self.first_name)

Подобным же образом вы должны убедиться, что методы get_absolute_url() и __str__() ведут себя как требуется, потому что они являются частью вашей бизнес логики. В случае функции get_absolute_url() вы можете быть уверены, что функция из Django reverse() была реализована правильно и, следовательно, вы тестируете только то, чтобы соответствующий вызов в отображении был правильно определен.

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

Ну что же, усвоив данную информацию, давайте перейдем к процессу определения и запуска тестов.

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

Django использует юнит-тестовый модуль — встроенный «обнаружитель» тестов, который находит тесты в текущей рабочей директории, в любом файле с шаблонным именем test*.py. Предоставляя соответствующие имена файлов, вы можете работать с любой структурой которая вас устраивает. Мы рекомендуем создать пакет для вашего тестирующего кода и, следовательно, отделить файлы моделей, отображений, форм и любые другие, от кода который будет использоваться для тестов. Например:

catalog/
  /tests/
    __init__.py
    test_models.py
    test_forms.py
    test_views.py

В проекте LocalLibrary создайте файловую структуру, указанную выше. Файл __init__.py должен быть пустым (так мы говорим Питону, что данная директория является пакетом). Вы можете создать три тестовых файла при помощи копирования и переименования файла-образца /catalog/tests.py.

Примечание: Скелет тестового файла /catalog/tests.py был создан автоматически когда мы выполняли построение скелета сайта Django. Является абсолютно «легальным» действием — поместить все ваши тесты в данный файл, тем не менее, если вы проводите тесты «правильно», то вы очень быстро придете к очень большому и неуправляемому файлу тестирования.

Можете удалить данный файл, поскольку больше он нам не понадобится.

Откройте /catalog/tests/test_models.py. Файл должен импортировать django. test.TestCase, как показано ниже:

from django.test import TestCase

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

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

class YourTestClass(TestCase):

    @classmethod
    def setUpTestData(cls):
        print("setUpTestData: Run once to set up non-modified data for all class methods. ")
        pass

    def setUp(self):
        print("setUp: Run once for every test method to setup clean data.")
        pass

    def test_false_is_false(self):
        print("Method: test_false_is_false.")
        self.assertFalse(False)

    def test_false_is_true(self):
        print("Method: test_false_is_true.")
        self.assertTrue(False)

    def test_one_plus_one_equals_two(self):
        print("Method: test_one_plus_one_equals_two.")
        self.assertEqual(1 + 1, 2)

Этот класс определяет два метода которые вы можете использовать для дотестовой настройки (например, создание какой-либо модели, или других объектов, которые вам понадобятся):

• setUpTestData() вызывается каждый раз перед запуском теста на уровне настройки всего класса. Вы должны использовать данный метод для создания объектов, которые не будут модифицироваться/изменяться в каком-либо из тестовых методов.
• setUp() вызывается перед каждой тестовой функцией для настройки объектов, которые могут изменяться во время тестов (каждая функция тестирования будет получать «свежую» версию данных объектов).

Примечание. Классы тестирования также содержат метод tearDown(), который мы пока не используем. Этот метод не особенно полезен для тестирования баз данных, поскольку базовый класс TestCase автоматически разрывает соединения с ними.

Далее идут несколько методов, которые используют функции Assert, проверяющие условия «истинно» (true), «ложно» (false) или равенство (AssertTrue, AssertFalse, AssertEqual). Если условия не выполняются как ожидалось, то это приводит к провалу теста и выводу соответствующего сообщения об ошибке на консоль.

Функции проверки утверждений AssertTrue, AssertFalse, AssertEqual реализованы в unittest.  В данном фреймворке существуют и другие подобные функции, а кроме того, специфические для Django функции проверки, например, перехода из/к отображению (assertRedirects), проверки использования какого-то конкретного шаблона (assertTemplateUsed) и так далее.

В обычной ситуации у вас нет необходимости вызывать функции print() из методов теста, как во фрагменте выше. Мы поступили так только для того, чтобы вы в консоле увидели порядок вызова тестовых функций класса.

Простейшим способом запуска всех тестов является применение следующей команды:

python3 manage.py test

Таким образом мы найдем в текущей директории все файлы с именем test*.py и запустим все тесты (у нас имеются несколько файлов для тестирования, но на данный момент, только /catalog/tests/test_models.py содержит какие-либо тесты). По умолчанию, тесты сообщат что-нибудь, только в случае провала.

Запустите тесты из корневой папки сайта LocalLibrary. Вы должны увидеть вывод, который похож на следующий.

>python manage.py test

Creating test database for alias 'default'...
setUpTestData: Run once to set up non-modified data for all class methods.
setUp: Run once for every test method to setup clean data. 
Method: test_false_is_false.
.setUp: Run once for every test method to setup clean data.
Method: test_false_is_true.
.setUp: Run once for every test method to setup clean data.
Method: test_one_plus_one_equals_two.
.
======================================================================
FAIL: test_false_is_true (catalog.tests.tests_models.YourTestClass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Github\django_tmp\library_w_t_2\locallibrary\catalog\tests\tests_models.py", line 22, in test_false_is_true
    self.assertTrue(False)
AssertionError: False is not true

----------------------------------------------------------------------
Ran 3 tests in 0.075s

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

Как видите, один тест провалился и мы можем точно увидеть в какой именно функции это произошло и почему (так и было задумано, поскольку False не равен True!).

Совет:  Самая важная вещь, которую нужно извлечь из тестового выхода выше, заключается в том, что это гораздо более ценно, если вы используете описательные/информативные имена для ваших объектов и методов.

Текст выделенный жирным, обычно не должен появляться в тестовом выводе (это результат работы функций print() в наших тестах). Он показывает, что вызов метода  setUpTestData() происходит один раз для всего класса в целом, а вызовыsetUp() осуществляются перед каждым методом.

Следующий раздел показывает как запускать отдельные тесты и как контролировать процесс вывода информации.

Еще больше тестовой информации

Если вы желаете получать больше информации о тестах вы должны изменить значение параметра verbosity. Например, для вывода списка успешных и неуспешных тестов (и всю информацию о том, как прошла настройка базы данных) вы можете установить значение verbosity равным «2»:

python3 manage. py test --verbosity 2

Доступными значениями для verbosity являются  0, 1 (значение по умолчанию), 2 и 3.

Запуск определенных тестов

Если вы хотите запустить подмножество тестов, тогда вам надо указать полный путь к вашему пакету, модулю/подмодулю, классу наследникуTestCase, или методу:

python3 manage.py test catalog.tests   
python3 manage.py test catalog.tests.test_models  
python3 manage.py test catalog.tests.test_models.YourTestClass 
python3 manage.py test catalog.tests.test_models.YourTestClass.test_one_plus_one_equals_two  

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

Примечание: Мы не будем расписывать все тесты, а просто покажем вам пример того, как они должны работать и что еще вы можете с ними сделать.

Модели

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

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

class Author(models.Model):
    first_name = models.CharField(max_length=100)
    last_name = models.CharField(max_length=100)
    date_of_birth = models.DateField(null=True, blank=True)
    date_of_death = models.DateField('Died', null=True, blank=True)

    def get_absolute_url(self):
        return reverse('author-detail', args=[str(self.id)])

    def __str__(self):
        return '%s, %s' % (self.last_name, self.first_name)

Откройте файл /catalog/tests/test_models. py и замените все его содержимое кодом, приведенном во фрагменте для тестирования модели Author (фрагмент представлен ниже).

В первой строке мы импортируем класс TestCase, а затем наследуемся от него, создавая класс с описательным именем (AuthorModelTest), оно поможет нам идентифицировать места провалов в тестах во время вывода информации на консоль. Затем мы создаем метод setUpTestData(), в котором создаем объект автора, который мы будем использовать в тестах, но нигде не будем изменять.

from django.test import TestCase



from catalog.models import Author

class AuthorModelTest(TestCase):

    @classmethod
    def setUpTestData(cls):
        
        Author.objects.create(first_name='Big', last_name='Bob')

    def test_first_name_label(self):
        author=Author.objects.get(id=1)
        field_label = author._meta.get_field('first_name').verbose_name
        self.assertEquals(field_label,'first name')

    def test_date_of_death_label(self):
        author=Author. objects.get(id=1)
        field_label = author._meta.get_field('date_of_death').verbose_name
        self.assertEquals(field_label,'died')

    def test_first_name_max_length(self):
        author=Author.objects.get(id=1)
        max_length = author._meta.get_field('first_name').max_length
        self.assertEquals(max_length,100)

    def test_object_name_is_last_name_comma_first_name(self):
        author=Author.objects.get(id=1)
        expected_object_name = '%s, %s' % (author.last_name, author.first_name)
        self.assertEquals(expected_object_name,str(author))

    def test_get_absolute_url(self):
        author=Author.objects.get(id=1)
        
        self.assertEquals(author.get_absolute_url(),'/catalog/author/1')

Тесты полей проверяют значения текстовых меток (verbose_name), включая их ожидаемую длину. Все методы имеют описательные имена, а их логика придерживается одной и той же структуры:

author=Author.objects.get(id=1)


field_label = author. _meta.get_field('first_name').verbose_name


self.assertEquals(field_label,'first name')  

Интересно отметить следующее:

• Мы не можем получить поле verbose_name напрямую через author.first_name.verbose_name, потому что author.first_name является строкой. Вместо этого, нам надо использовать атрибут _meta объекта автора для получения того экземпляра поля, который будет использоваться для получения дополнительной информации.
• Мы выбрали метод assertEquals(field_label,'first name') вместо  assertTrue(field_label == 'first name'), потому что, в случае провала теста, в выводе будет указано какое именно значение содержит метка и это немного облегчит нам задачу по отладке кода.

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

Кроме того, нам надо провести тесты наших собственных методов. Они просто проверяют, что имена объектов имеют следующие значения «Last Name, First Name» и что URL-адрес, по которому мы получаем экземпляр Author, такой как ожидается.

def test_object_name_is_last_name_comma_first_name(self):
    author=Author.objects.get(id=1)
    expected_object_name = '%s, %s' % (author.last_name, author.first_name)
    self.assertEquals(expected_object_name,str(author))

def test_get_absolute_url(self):
    author=Author.objects.get(id=1)
    
    self.assertEquals(author.get_absolute_url(),'/catalog/author/1')

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

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

Примечание: Измените значение метки для поля date_of_death (/catalog/models.py) на «died» и перезапустите тесты.

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

Формы

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

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

Рассмотрим форму для обновления книг. Она имеет только одно поле обновления даты, которое будет иметь текстовую метку и вспомогательный текст, который вам надо проверить.

class RenewBookForm(forms.Form):
    """
    Форма обновления книг для библиотекарей
    """
    renewal_date = forms.DateField(help_text="Enter a date between now and 4 weeks (default 3).")

    def clean_renewal_date(self):
        data = self.cleaned_data['renewal_date']

        
        if data < datetime.date.today():
            raise ValidationError(_('Invalid date - renewal in past'))
        
        if data > datetime.date.today() + datetime.timedelta(weeks=4):
            raise ValidationError(_('Invalid date - renewal more than 4 weeks ahead'))

        
        return data

Откройте файл /catalog/tests/test_forms. py и замените весь существующий в нем код, следующим кодом теста для формы RenewBookForm. Мы начали его с импорта нашей формы и некоторых библиотек Python и Django, которые погут нам провести тесты. Затем, тем же способом как мы делали для моделей, объявляем тестовый класс нашей формы, то есть применяя описательное имя класс наследника TestCase.

from django.test import TestCase



import datetime
from django.utils import timezone
from catalog.forms import RenewBookForm

class RenewBookFormTest(TestCase):

    def test_renew_form_date_field_label(self):
        form = RenewBookForm()
        self.assertTrue(form.fields['renewal_date'].label == None or form.fields['renewal_date'].label == 'renewal date')

    def test_renew_form_date_field_help_text(self):
        form = RenewBookForm()
        self.assertEqual(form.fields['renewal_date'].help_text,'Enter a date between now and 4 weeks (default 3).')

    def test_renew_form_date_in_past(self):
        date = datetime. date.today() - datetime.timedelta(days=1)
        form_data = {'renewal_date': date}
        form = RenewBookForm(data=form_data)
        self.assertFalse(form.is_valid())

    def test_renew_form_date_too_far_in_future(self):
        date = datetime.date.today() + datetime.timedelta(weeks=4) + datetime.timedelta(days=1)
        form_data = {'renewal_date': date}
        form = RenewBookForm(data=form_data)
        self.assertFalse(form.is_valid())

    def test_renew_form_date_today(self):
        date = datetime.date.today()
        form_data = {'renewal_date': date}
        form = RenewBookForm(data=form_data)
        self.assertTrue(form.is_valid())

    def test_renew_form_date_max(self):
        date = timezone.now() + datetime.timedelta(weeks=4)
        form_data = {'renewal_date': date}
        form = RenewBookForm(data=form_data)
        self.assertTrue(form.is_valid())

Первые две функции проверяют текст который должны содержать поля label и help_text. Доступ к полю мы получаем при помощи словаря (то есть, form.fields['renewal_date']). Отметим, что мы должны проверять содержит ли метка значение None, иначе в поле текста метки вы увидите «None«.

Оставшиеся функции проверяют валидность дат, то есть их нахождение внутри определенного интервала, а также невалидность для значений, которые находятся вне заданного интервала. Для получения исходного значения мы использовали функцию получения текущей даты (datetime.date.today()), а также функцию datetime.timedelta() (которая принимает определенное число дней, или недель). Затем мы просто создали форму, передавая ей наши данные и проверяя ее на валидность.

Примечание: В данном примере мы не использовали ни базу данных, ни тестовый клиент. Рассмотрите модификацию этих тестов при помощи класса SimpleTestCase.

Нам также надо бы проверять возникновение ошибок, которые появляются если форма не валидна. Но, обычно, это относится к процессу вывода информации, таким образом, мы позаботимся об этом в следующем разделе.

На этом с формами можно закончить; у нас имеются и другие тесты, но они были созданы обобщенными классами отображения для редактирования! Запустите тесты и убедитесь, что наш код все еще им соответствует!

Отображения

Для проверки поведения отображения мы используем тестовый клиет Django Client. Данный класс действует как упрощенный веб-браузер который мы применяем для имитации  GET и POST запросов и проверки ответов. Про ответы мы можем узнать почти все, начиная с низкоуровневого HTTP (итоговые заголовки и коды статусов) и вплоть до применяемых шаблонов, которые используются для HTML-рендера, а также контекста, который передается в соответствующий  шаблон. Кроме того, мы можем отследить последовательность перенаправлений (если имеются), проверить URL-адреса и коды статусов на каждом шаге. Все это позволит нам проверить, что каждое отображение выполняет то, что ожидается.

Давайте начнем с одного из простейших отображений которое возвращает список всех авторов. Вы можете его увидеть по URL-адресу /catalog/authors/ (данный URL-адрес можно найти в разделе приложения catalog,  в файле настроек urls.py по имени  ‘authors’).

class AuthorListView(generic.ListView):
    model = Author
    paginate_by = 10

Поскольку это обобщенное отображение списка, то почти все за нас делает Django. Если вы доверяете Django, то единственной вещью, которую вам нужно протестировать, является переход к данному отображению по указанному URL-адресу. Таким образом, если вы применяете методику TDD (test-driven development, разработка через тесты), то начните проект с написания тестов, которые будут проверять, что данное отображение выводит всех авторов и, к тому же, например, блоками по 10.

Откройте файл /catalog/tests/test_views.py замените все его содержимое на следующий код теста для класса AuthorListView. Как и ранее, мы импортируем нашу модель и некоторые полезные классы. В методе setUpTestData() мы задаем число объектов класса Author которые мы тестируем при постраничном выводе.

from django.test import TestCase



from catalog.models import Author
from django.urls import reverse

class AuthorListViewTest(TestCase):

    @classmethod
    def setUpTestData(cls):
        
        number_of_authors = 13
        for author_num in range(number_of_authors):
            Author.objects.create(first_name='Christian %s' % author_num, last_name = 'Surname %s' % author_num,)

    def test_view_url_exists_at_desired_location(self):
        resp = self.client.get('/catalog/authors/')
        self.assertEqual(resp.status_code, 200)

    def test_view_url_accessible_by_name(self):
        resp = self.client.get(reverse('authors'))
        self.assertEqual(resp.status_code, 200)

    def test_view_uses_correct_template(self):
        resp = self.client.get(reverse('authors'))
        self. assertEqual(resp.status_code, 200)

        self.assertTemplateUsed(resp, 'catalog/author_list.html')

    def test_pagination_is_ten(self):
        resp = self.client.get(reverse('authors'))
        self.assertEqual(resp.status_code, 200)
        self.assertTrue('is_paginated' in resp.context)
        self.assertTrue(resp.context['is_paginated'] == True)
        self.assertTrue( len(resp.context['author_list']) == 10)

    def test_lists_all_authors(self):
        
        resp = self.client.get(reverse('authors')+'?page=2')
        self.assertEqual(resp.status_code, 200)
        self.assertTrue('is_paginated' in resp.context)
        self.assertTrue(resp.context['is_paginated'] == True)
        self.assertTrue( len(resp.context['author_list']) == 3)

Все тесты используют клиент (принадлежащего классу TestCase, от которого мы наследовались) для имитации GET-запроса и получения ответа (resp). Первая версия проверяет заданный URL-адрес (заметьте, — просто определенный путь без указания домена), в то время как второй генерирует URL-адрес при помощи его имени, указанного в настройках.

resp = self.client.get('/catalog/authors/')
resp = self.client.get(reverse('authors'))

Когда мы получаем ответ, то мы извлекаем код статуса, используемый шаблон, «включен» ли постраничный вывод, количество элементов в подмножестве (на странице) и общее число элементов.

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

Отображения и регистрация пользователей

В некоторых случаях вам нужно провести тесты отображений к которым имеют доступ только зарегистрированные пользователи. Например, LoanedBooksByUserListView очень похоже на наше предыдущее отображение, но доступно только для залогинившихся пользователей и показывает только те записи (BookInstance), которые соответствуют текущему пользователю, имеют статус ‘on loan’ (книга взята домой), а также забронированны.

from django.contrib.auth.mixins import LoginRequiredMixin

class LoanedBooksByUserListView(LoginRequiredMixin,generic.ListView):
    """
    Обобщенный класс отображения списка взятых книг текущим пользователем
    """
    model = BookInstance
    template_name ='catalog/bookinstance_list_borrowed_user.html'
    paginate_by = 10

    def get_queryset(self):
        return BookInstance.objects.filter(borrower=self.request.user).filter(status__exact='o').order_by('due_back')

Добавьте тестовый код следующего фрагмента в /catalog/tests/test_views.py. В нем, для создания нескольких аккаунтов и  объектов BookInstance которые будут использоваться в дальнейших тестах, мы используем метод SetUp() (вместе с соответствующими книгами и другими записями). Половина книг бронируется  тестовыми пользователями, но в начале для них всех мы устанавливаем статус «доступно». Использование метода SetUp() предпочтительнее чем setUpTestData(), поскольку в дальнейшем мы будем модифицировать некоторые объекты.

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

import datetime
from django.utils import timezone

from catalog.models import BookInstance, Book, Genre, Language
from django.contrib.auth.models import User 

class LoanedBookInstancesByUserListViewTest(TestCase):

    def setUp(self):
        
        test_user1 = User.objects.create_user(username='testuser1', password='12345')
        test_user1.save()
        test_user2 = User.objects.create_user(username='testuser2', password='12345')
        test_user2.save()

        
        test_author = Author.objects.create(first_name='John', last_name='Smith')
        test_genre = Genre. objects.create(name='Fantasy')
        test_language = Language.objects.create(name='English')
        test_book = Book.objects.create(title='Book Title', summary = 'My book summary', isbn='ABCDEFG', author=test_author, language=test_language)
        
        genre_objects_for_book = Genre.objects.all()
        test_book.genre.set(genre_objects_for_book) 
        test_book.save()

        
        number_of_book_copies = 30
        for book_copy in range(number_of_book_copies):
            return_date= timezone.now() + datetime.timedelta(days=book_copy%5)
            if book_copy % 2:
                the_borrower=test_user1
            else:
                the_borrower=test_user2
            status='m'
            BookInstance.objects.create(book=test_book,imprint='Unlikely Imprint, 2016', due_back=return_date, borrower=the_borrower, status=status)

    def test_redirect_if_not_logged_in(self):
        resp = self.client.get(reverse('my-borrowed'))
        self.assertRedirects(resp, '/accounts/login/?next=/catalog/mybooks/')

    def test_logged_in_uses_correct_template(self):
        login = self. client.login(username='testuser1', password='12345')
        resp = self.client.get(reverse('my-borrowed'))

        
        self.assertEqual(str(resp.context['user']), 'testuser1')
        
        self.assertEqual(resp.status_code, 200)

        
        self.assertTemplateUsed(resp, 'catalog/bookinstance_list_borrowed_user.html')

Если пользователь не залогирован то, чтобы убедиться в том что отображение перейдет на страницу входа (логирования), мы используем метод assertRedirects, что продемонстрировано в методе test_redirect_if_not_logged_in(). Затем мы осуществляем вход для пользователя и проверям что полученный статус status_code равен 200 (успешно). 

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

    def test_only_borrowed_books_in_list(self):
        login = self. client.login(username='testuser1', password='12345')
        resp = self.client.get(reverse('my-borrowed'))

        
        self.assertEqual(str(resp.context['user']), 'testuser1')
        
        self.assertEqual(resp.status_code, 200)

        
        self.assertTrue('bookinstance_list' in resp.context)
        self.assertEqual( len(resp.context['bookinstance_list']),0)

        
        get_ten_books = BookInstance.objects.all()[:10]

        for copy in get_ten_books:
            copy.status='o'
            copy.save()

        
        resp = self.client.get(reverse('my-borrowed'))
        
        self.assertEqual(str(resp.context['user']), 'testuser1')
        
        self.assertEqual(resp.status_code, 200)

        self.assertTrue('bookinstance_list' in resp.context)

        
        for bookitem in resp.context['bookinstance_list']:
            self.assertEqual(resp.context['user'], bookitem.borrower)
            self.assertEqual('o', bookitem.status)

    def test_pages_ordered_by_due_date(self):

        
        for copy in BookInstance. objects.all():
            copy.status='o'
            copy.save()

        login = self.client.login(username='testuser1', password='12345')
        resp = self.client.get(reverse('my-borrowed'))

        
        self.assertEqual(str(resp.context['user']), 'testuser1')
        
        self.assertEqual(resp.status_code, 200)

        
        self.assertEqual( len(resp.context['bookinstance_list']),10)

        last_date=0
        for copy in resp.context['bookinstance_list']:
            if last_date==0:
                last_date=copy.due_back
            else:
                self.assertTrue(last_date <= copy.due_back)

Если хотите, то вы, безусловно, можете добавить тесты проверяющие постраничный вывод!

Тестирование форм и отображений

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

В качестве демонстрации давайте напишем некоторые тесты для отображения, которые отвечают за обновление книг(renew_book_librarian()):

from .forms import RenewBookForm

@permission_required('catalog.can_mark_returned')
def renew_book_librarian(request, pk):
    """
    Функция отображения обновления экземпляра BookInstance библиотекарем
    """
    book_inst=get_object_or_404(BookInstance, pk = pk)

    
    if request.method == 'POST':

        
        form = RenewBookForm(request.POST)

        
        if form.is_valid():
            
            book_inst.due_back = form.cleaned_data['renewal_date']
            book_inst.save()

            
            return HttpResponseRedirect(reverse('all-borrowed') )

    
    else:
        proposed_renewal_date = datetime.date. today() + datetime.timedelta(weeks=3)
        form = RenewBookForm(initial={'renewal_date': proposed_renewal_date,})

    return render(request, 'catalog/book_renew_librarian.html', {'form': form, 'bookinst':book_inst})

Нам надо проверить что к данному отображению имеют доступ только те пользователи, которые имеют разрешение типа can_mark_returned, а кроме того, что пользователи перенаправляются на страницу ошибки HTTP 404  если они пытаются обновить экземпляр книги  BookInstance, который не существует. Мы должны проверить что начальное значение формы соответствует дате через 3 недели в будущем, а также то, что если форма прошла валидацию, то мы переходим на страницу отображения книг «all-borrowed» (забронированных). Для тестов, отвечающих за проверку «провалов», мы также должны удостовериться что они отправляют соответствующие сообщения об ошибках.

В нижнюю часть файла /catalog/tests/test_views.py добавьте класс тестрования (показан во фрагменте, ниже). Он создает двух пользователей и два экземпляра книги, но только один пользователь получает необходимый доступ к соответствующему отображению. Код, который «присваивает» соответствующий доступ, выделен в коде жирным:

from django.contrib.auth.models import Permission 

class RenewBookInstancesViewTest(TestCase):

    def setUp(self):
        
        test_user1 = User.objects.create_user(username='testuser1', password='12345')
        test_user1.save()

        test_user2 = User.objects.create_user(username='testuser2', password='12345')
        test_user2.save()
        permission = Permission.objects.get(name='Set book as returned')
        test_user2.user_permissions.add(permission)
        test_user2.save()

        
        test_author = Author.objects.create(first_name='John', last_name='Smith')
        test_genre = Genre.objects.create(name='Fantasy')
        test_language = Language.objects.create(name='English')
        test_book = Book.objects.create(title='Book Title', summary = 'My book summary', isbn='ABCDEFG', author=test_author, language=test_language,)
        
        genre_objects_for_book = Genre. objects.all()
        test_book.genre=genre_objects_for_book
        test_book.save()

        
        return_date= datetime.date.today() + datetime.timedelta(days=5)
        self.test_bookinstance1=BookInstance.objects.create(book=test_book,imprint='Unlikely Imprint, 2016', due_back=return_date, borrower=test_user1, status='o')

        
        return_date= datetime.date.today() + datetime.timedelta(days=5)
        self.test_bookinstance2=BookInstance.objects.create(book=test_book,imprint='Unlikely Imprint, 2016', due_back=return_date, borrower=test_user2, status='o')

В нижнюю часть класса тестирования добавьте следующие методы (из следующего фрагмента). Они проверяют, что только пользователь с соответствущим доступом (testuser2) имеет доступ к отображению. Мы проверяем все случаи: когда пользователь не залогинился, когда залогинился, но не имеет соответствующего доступа, когда имеет доступ, но не является заемщиком книги (тест должен быть успешным), а также, что произойдет если попытаться получить доступ к книге BookInstance которой не существует. Кроме того, мы проверям то, что используется правильный (необходимый) шаблон.

    def test_redirect_if_not_logged_in(self):
        resp = self.client.get(reverse('renew-book-librarian', kwargs={'pk':self.test_bookinstance1.pk,}) )
        
        self.assertEqual( resp.status_code,302)
        self.assertTrue( resp.url.startswith('/accounts/login/') )

    def test_redirect_if_logged_in_but_not_correct_permission(self):
        login = self.client.login(username='testuser1', password='12345')
        resp = self.client.get(reverse('renew-book-librarian', kwargs={'pk':self.test_bookinstance1.pk,}) )

        
        self.assertEqual( resp.status_code,302)
        self.assertTrue( resp.url.startswith('/accounts/login/') )

    def test_logged_in_with_permission_borrowed_book(self):
        login = self.client.login(username='testuser2', password='12345')
        resp = self.client.get(reverse('renew-book-librarian', kwargs={'pk':self.test_bookinstance2.pk,}) )

        
        self. assertEqual( resp.status_code,200)

    def test_logged_in_with_permission_another_users_borrowed_book(self):
        login = self.client.login(username='testuser2', password='12345')
        resp = self.client.get(reverse('renew-book-librarian', kwargs={'pk':self.test_bookinstance1.pk,}) )

        
        self.assertEqual( resp.status_code,200)

    def test_HTTP404_for_invalid_book_if_logged_in(self):
        import uuid
        test_uid = uuid.uuid4() 
        login = self.client.login(username='testuser2', password='12345')
        resp = self.client.get(reverse('renew-book-librarian', kwargs={'pk':test_uid,}) )
        self.assertEqual( resp.status_code,404)

    def test_uses_correct_template(self):
        login = self.client.login(username='testuser2', password='12345')
        resp = self.client.get(reverse('renew-book-librarian', kwargs={'pk':self.test_bookinstance1.pk,}) )
        self.assertEqual( resp.status_code,200)

        
        self.assertTemplateUsed(resp, 'catalog/book_renew_librarian. html')

Добавьте еще один тестовый метод, показанный ниже. Он проверяет что начальная дата равна трем неделям в будущем. Заметьте, что мы имеем возможность получить доступ к начальному значению из поля формы (выделено жирным).

    def test_form_renewal_date_initially_has_date_three_weeks_in_future(self):
        login = self.client.login(username='testuser2', password='12345')
        resp = self.client.get(reverse('renew-book-librarian', kwargs={'pk':self.test_bookinstance1.pk,}) )
        self.assertEqual( resp.status_code,200)

        date_3_weeks_in_future = datetime.date.today() + datetime.timedelta(weeks=3)
        self.assertEqual(resp.context['form'].initial['renewal_date'], date_3_weeks_in_future )

Следующий тест (тоже добавьте его в свой класс) проверяет что отображение, в случае успеха, перенаправляет пользователя к списку всех забронированных книг. Здесь мы показываем как при помощи клиента вы можете создать и передать данные в POST-запросе. Данный запрос передается вторым аргументом в пост-функцию и представляет из себя словарь пар ключ/значение.

    def test_redirects_to_all_borrowed_book_list_on_success(self):
        login = self.client.login(username='testuser2', password='12345')
        valid_date_in_future = datetime.date.today() + datetime.timedelta(weeks=2)
        resp = self.client.post(reverse('renew-book-librarian', kwargs={'pk':self.test_bookinstance1.pk,}), {'renewal_date':valid_date_in_future} )
        self.assertRedirects(resp, reverse('all-borrowed') )

Вместо перехода к отображению all-borrowed, добавленого в качестве домашнего задания, вы можете перенаправить пользователя на домашнюю страницу ‘/’. В таком случае, исправьте две последние строки тестового кода на код, показанный ниже. Присваивание follow=True, в запросе, гарантирует что запрос вернет окончательный URL-адрес пункта назначения (следовательно проверяется /catalog/, а не /).

 resp = self.client.post(reverse('renew-book-librarian', kwargs={'pk':self.test_bookinstance1.pk,}), {'renewal_date':valid_date_in_future},follow=True )
 self.assertRedirects(resp, '/catalog/')

Скопируйте две последние функции в класс, представленные ниже. Они тоже проверяют  POST-запросы, но для случая неверных дат. Мы используем функцию assertFormError(), чтобы проверить сообщения об ошибках.

    def test_form_invalid_renewal_date_past(self):
        login = self.client.login(username='testuser2', password='12345')
        date_in_past = datetime.date.today() - datetime.timedelta(weeks=1)
        resp = self.client.post(reverse('renew-book-librarian', kwargs={'pk':self.test_bookinstance1.pk,}), {'renewal_date':date_in_past} )
        self.assertEqual( resp.status_code,200)
        self.assertFormError(resp, 'form', 'renewal_date', 'Invalid date - renewal in past')

    def test_form_invalid_renewal_date_future(self):
        login = self. client.login(username='testuser2', password='12345')
        invalid_date_in_future = datetime.date.today() + datetime.timedelta(weeks=5)
        resp = self.client.post(reverse('renew-book-librarian', kwargs={'pk':self.test_bookinstance1.pk,}), {'renewal_date':invalid_date_in_future} )
        self.assertEqual( resp.status_code,200)
        self.assertFormError(resp, 'form', 'renewal_date', 'Invalid date - renewal more than 4 weeks ahead')

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

Шаблоны

Django предоставляет API для тестирования, которое проверяет что функции отображения вызывают правильные шаблоны, а также позволяют убедиться, что им передается соответствующая информация. Кроме того, в Django имеется возможность использовать сторонние API для проверок того, что ваш HTML показывает то, что надо.

Django фреймворк для тестирования помогает вам создавать эффективные юнит- и интеграционные тесты — мы рассмотрели только небольшую часть того, что может делать фреймворк unittest и совсем не упоминали дополнения Django (например, посмотрите на модуль unittest. mock, который подключает сторонние библиотеки тестирования).

Из всего множества сторонних инструментов тестирования, мы кратко опишем возможности двух:

• Coverage: Это инструмент Python, который формирует отчеты о том, какое количество кода выполняется во время проведения тестов. Это полезно для уточнения степени «покрытия» кода тестами.
• Selenium это фреймворк проведения автоматического тестирования в настоящем браузере. Он позволяет вам имитировать взаимодействие пользователя с вашим сайтом (что является следующим шагом в проведении интеграционных тестов).

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

class AuthorCreate(PermissionRequiredMixin, CreateView):
    model = Author
    fields = '__all__'
    initial={'date_of_death':'12/10/2016',}
    permission_required = 'catalog.can_mark_returned'

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

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

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

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

Фреймворки для юнит-тестов C++ | OTUS

C++ →

Полезные материалы по С++

Теги: c++, фреймворки, программирование на c++, catch, мок-фреймворки, юнит-тесты, юнит-тестирование, gmock, gtest, mettle, boost.test, hippomocks

Для написания юнит-тестов и моков вам понадобятся хорошие фреймворки. К счастью, сегодня существует много разных программ с широкой функциональностью. Рассмотрим некоторые из них.

1. GTest/Gmock — мощная пара, которая считается по сути стандартом модульного тестирования в языке программирования C++. Можно даже сказать, что на протяжении долгого времени именно GMock был той единственной движущей силой в мире мок-фреймворков на C++. Преимущество вышеописанного инструмента очевидно: если у вас есть GMock, то GTest вы получите в комплекте. Но есть и недостаток: нужно собирать GTest/GMock в одной конфигурации с проектом, а это уже может заставить вас немного попотеть.
2. Catch — фреймворк для модульного тестирования, совместимый не только с C++. Развёртывание с его помощью производится посредством подключения одного заголовочного файла к тестируемому проекту, в результате чего можно сразу приступать к работе. У фреймворка есть много плюсов для «плюсов»: мощнейший функционал для создания assert’ов, удивительная фича под названием «sections», именованные тесты и т. д. В целом, Catch — это набор простых, но полезных инструментов.
3. Mettle — этот фреймворк чуть отличается от других, однако в нём собрано множество хороших идей. Это и полная настройка assert’ов и различный синтаксис, добавляемый этой возможностью. Можно уверенно сказать, что данный инструмент поможет лучше понять модульное тестирование и облегчит его использование.
4. Boost.Test — не что иное, как часть boost-библиотеки и некоторых проектов, в которых она применяется. Некоторые считают, что данный фреймворк слишком перегружен. Впрочем, у него есть и свои поклонники.

А что насчёт мок-фреймворков?

Как уже упоминалось, GMock был единственным мок-фреймворком для C++ в течение длительного времени. На тот момент это было связано с большой популярностью Google и GTest. Но сегодня у разработчиков C++ существует масса других вариантов:

— есть инструменты типа Trompeloeil — они имеют понятный синтаксис и разворачиваются посредством подключения одного заголовочного файла;
— есть просто потрясающие библиотеки, такие как FakeIt. Они помогают программистам писать фиктивные объекты (стабы и моки), используя для этого минимум кода и синтаксис, знакомый всем, кто когда-либо использовал Mockito (Java) либо какой-нибудь .NET-фреймворк для написания моков;
— остаётся добавить, что есть ещё и HippoMocks, который может стать очередной альтернативой, на которую стоит обратить внимание уже сейчас.

Хотите увидеть синтаксис вышеописанных фреймворков? Это можно сделать в следующем репозитории на GitHub. И не забывайте писать в комментариях, какие фреймворки предпочитаете вы.

Материал подготовлен специально для OTUS и является отрывком из статьи Д. Хэлпера «Getting started with C++ unit testing».

Изучаем юнит-тестирование с NUnit на C#

Создайте с помощью этого курса прочную основу для понимания юнит тестирования.

Вся суть курса заключается в том, чтобы научить вас писать эффективные юнит тесты при помощи языка программирования C#, а также NUnit в качестве фреймворка юнит тестирования. По пути мы изучим концепции, связанные с юнит-тестированием. Сегодня юнит тестирование — это абсолютно необходимый навык, и владение им требуется от каждого профессионального разработчика. Компании предполагают, что разработчики умеют писать юнит тесты, включая все наиболее важные навыки, такие как изолирующая (подставная) разработка и разработка через тестирование (вкратце TDD). Этот курс не охватывает все функции NUnit. Он намного интереснее. 

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

Содержание и обзор 

Этот курс в первую очередь ориентирован на начинающих разработчиков. Он обеспечивает прочную теоретическую базу, подкреплённую большим количеством практического материала. 

Мы начнём с основ юнит тестирования. Что такое юнит тестирование? Какие фреймворки юнит тестирования существуют? Как прогонять юнит тесты, и как их отлаживать? Ознакомившись с основами, мы перейдём к фреймворку NUnit. Вы узнаете как устанавливать фреймворк и запускать тесты. Затем мы поговорим об основах утверждений и модели подготовка-действие-утверждение (Arrange/Act/Assert). Также мы разберём такие особенности NUnit как: 

• Запуск тестов из консоли 

• Подготовительные и очищающие юнит тесты 

• Параметризованные тесты 

• Группировка и игнорирование тестов

Практикуясь в написании юнит тестов, невозможно избежать применения подставок. В целом, мне больше нравится слово «дублёр». Кстати, вы узнаете, в чём заключается разница между следующими понятиями: 

• Дублёр 

• Подделка 

• Пустышка 

• Заглушка 

• Подставка 

Вы узнаете, как вручную прописывать дублёры. Также на простом примере мы посмотрим, как использовать для работы с подставками. Для демонстрации я буду использовать фреймворк NSubstitute. 

В конце этого раздела мы ознакомимся с двумя ключевыми подходами к юнит тестированию: классическая или детройтская школа и лондонская школа юнит тестирования. 

Отдельно мы изучим основы разработки через тестирование (TDD). Сложно представить современного профессионального разработчика, который не знает что это такое, поэтому мы подробно разберем, в чём заключается разработка через тестирование. Также мы посмотрим на методику «красный-зелёный-рефакторинг» в действии. 

Этот курс был бы неполным без лучших практик по написанию юнит тестов. Мы рассмотрим основные концепции современного подхода к юнит тестированию под названием «прагматическое юнит тестирование». Вы увидите, какие проблемы ставят статические классы и объекты-одиночки перед юнит тестированием. Они усложняют юнит тестирование кода. Затем мы поговорим о проблемах, связанных с извлечением интерфейсов только ради создания прокладки (shim) для внедрения зависимостей. 

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

Итак, вкратце, курс охватывает следующие темы: 

• Основные понятие юнит тестирования 

• NUnit и его основные особенности 

• Дублёры, включая подделки, пустышки, заглушки, шпионы и подставки 

• Как писать ручные дублёры и как использовать подставной Фреймворк 

• Разработка через тестирование (TDD), методика «красный-зелёный-рефакторинг» 

• Множество лучших практик по написанию юнит тестов 

Наконец, мы повторим всё изученное и попробуем понять, что делать дальше, чтобы лучше овладеть полученными навыки.  

Подход к обучению 

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

Зачисляйтесь на курс и удовлетворите свои потребности в новых знаниях! 

что, как и когда тестировать?

Оригинальная публикация: https://habrahabr.ru/company/jugru/blog/329372/

Тестирование программного кода — кропотливый и сложный процесс. Львиную долю работы в нем совершают unit-тесты. Пока они не «загорятся зеленым», тестировать дальше смысла нет. 

Как же писать unit-тесты правильно? Стоит ли гнаться за 100% покрытием? С какими сложностями приходится сталкиваться инженерам на практике? Своим опытом делятся Marc Philipp и Всеволод Брекелов. 

Marc Philipp – один из основных разработчиков фреймворка JUnit 5 – инструмента для Java-тестировщиков. В данный момент работает в качестве инженера в немецкой компании LogMeIn над облачными SaaS-решениями.

Всеволод Брекелов — Senior QA Engineer в компании Grid Dynamics, более 5 лет занимается тестированием, имеет опыт построения автоматизации тестирования с нуля.

— В статьях про unit-тестирование в качестве примеров обычно приводят тестирование методов и классов калькулятора. Такие примеры могут показать сложность реальных задач? С чем приходится сталкиваться тестировщику полнофункциональных программ?

Marc Philipp: Действительно, на примерах с калькулятором невозможно показать сложность реальных задач. Они выбраны в статьях для того, чтобы читатели могли сосредоточиться на понимании подходов unit-тестирования без необходимости разбора сложного кода. Хотя эти примеры очень простые, они хорошо демонстрируют основную идею и принципы unit-тестирования. В реальной жизни тестируемый код должен быть изначально написан с учетом того, что по нему будет проводиться Unit-тестирование. Один из способов обеспечить это — писать тесты до написания кода или практически одновременно с ним. Когда у вас есть код, адаптированный к тестированию, написание unit-тестов не на много сложнее, чем для калькулятора.

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

К примеру, по запросу «unit тестирование java» можно быстро найти статью на Хабре. Она опубликована довольно давно, но не потеряла своей актуальности.

Что касается особенностей работы, я бы выделил следующие группы тестировщиков (надеюсь никого не обидеть):

• Back-end – могут писать системные, интеграционные, компонентные, юнит тесты (почему бы и нет?).
• Front-end – могут писать как e2e тесты, так и компонентные, так и юнит тесты.
• DB — занимаются тестированием данных/самой БД.
• Performance – тут вроде бы очевидно.
• Infrastructure – занимаются больше вопросами «около-девопсными».
• Mobile testing(iOS, Androind, IoT) — сейчас очень модно стало отделять таких инженеров, хотя на мой взгляд это все о том же Back-end/Front-end.

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

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

— Каждый тест должен проверять одну вещь. Насколько полно на практике удается выполнить это условие? Как вы боретесь с зависимостями, какие фреймворки используете?

Marc Philipp: При написании unit-тестов обычно берется один образец входных данных из класса эквивалентности в тестируемой проблемной области. Конечно, вы должны сначала определить эти самые классы эквивалентности. В каждом тесте вы добавляете assertion только для тех свойств, которые релевантны вашему тесту. Не следует копипастить одни и те же assertions в каждый новый тест и прогонять их. Когда у вас есть зависимости, влияющие на работу юнита, подумайте об использовании стабов или моков, чтобы сохранить независимость теста.

Многие наши юнит-тесты для JUnit 5 используют моки, создаваемые mocking-фреймворком (Mockito в нашем случае). Как я уже говорил выше, они очень полезны для тестирования изолированного кода. Главная задача при этом — убедиться, что ваш мок ведет себя аналогично реальному коду. В противном случае тесты станут бессмысленными.

Всеволод Брекелов: Да, есть мнение: один юнит тест — один assertion. На практике такое я видел очень редко. Думаю, что это уже философия команды. Множественные assertions вполне себе имеют место.

Если мы проводим юнит тесты, а не компонентные, то все зависимости изолируем (моки, стабы — все в ваших руках). Тут нет каких-то сложностей на мой взгляд. А если и появляются, то StackOverflow точно поможет. 

Так как я пишу на Java/JavaScript(Angular), то использую обычные популярные тулы:
на Java – Mockito/EasyMock. Для компонентных тестов написать свой responsive mock — тоже хорошая идея! Всем советую.

JavaScript – ngMock. Кстати, для компонентых тестов очень классная тема – AngularPlayground. 

— Как найти компромисс между трудовыми и финансовыми затратами на тестирование и качеством итогового софта при реализации «горящих» проектов? Как обычно вы аргументируете важность полноценного тестирования в таких случаях?

Marc Philipp: По моему опыту, вы не можете спасти «горящий» проект, пропустив тесты. Написание unit-тестов является неотъемлемой частью разработки программного обеспечения. Без него у вас нет возможности узнать, действительно ли ваш код выполняет то, что, по вашему мнению, он должен делать. Вы не сможете ничего быстро починить, так как не поймете, где что сломалось. Как сказалUncleBob, «единственный способ быстро поехать — это хорошо идти».

Всеволод Брекелов: Думаю, тут нет однозначного ответа. Скорее, помогает опыт работы и тип проекта. Если вы делаете медицинский проект или строите ракету, то о важности тестирования не приходиться говорить. Если пилите стартап за неделю – то какие тесты?

Очень важно организовать процесс, чтобы избежать внезапных багов и неправильно реализованных требований. Что такое правильный процесс? Конечно, есть Agile Manifesto, на который многие смотрят при организации процесса, но все равно что-то не выходит. Можно взять и построить процесс ради процесса. А можно и наоборот, последовать за http://programming-motherfucker.com/.

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

— Какие приемы помогают сократить время и трудовые затраты на тестирование?

Marc Philipp: «Тестирование» — перегруженный термин. Это может означать что угодно: модульное тестирование, ручное тестирование, тестирование производительности… По моему опыту, ручное тестирование, то есть ручное выполнение плана пошагового прохождения тестовых примеров, действительно дорого и часто не так эффективно, как вы думаете. Более того, автоматизация этих скучных тестов имеет смысл только в определенной степени. Тем не менее, вы должны действительно следовать тестовой пирамиде, а не писать слишком много этих end-to-end/UI тестов. Большинство ваших тестов должны быть реальными unit-тестами: независимые, быстрые тесты, которые вы можете выполнять очень часто. Написание этих тестов относительно дешево, особенно если вы знаете свои инструменты. Они очень надежны, поэтому вы не будете тратить время на их актуализацию. UI и Integration тесты всегда будут более хрупкими из-за огромного количества задействованных компонентов.

Всеволод Брекелов: Есть хороший прием — писать меньше кода.

Главное – это понимание процесса и того, что вы хотите решить (или протестировать).
Всегда нужно адекватно оценивать бюджет и время. Что это значит? Если вы можете себе позволить вливать кучу денег в приближение к 100% coverage — why not? Хозяин – барин.

Если у вас нет денег на автотесты (которые, как известно, отбиваются в основном в долгоиграющих проектах), то толпа ручных тестировщиков – ваш вариант.

Если не впадать в крайности, то самая частая ошибка — это написание e2e тестов пачками до потери пульса до того, как написаны юнит тесты, компонентные тесты, интеграционные тесты на Backend, Frontend, DB, Performance и тд. Эта тенденция, вероятно, следует от модных BDD подходов (я их не очень люблю). К чему это все приводит?

Первая степень «опьянения» — у вас начинает реально работать автоматизация. Ручные тест кейсы вы заменяете на автоматические. Тестировщики начинают радоваться. Менеджеры начинают думать, что вот-вот сэкономят.

Вторая степень — тестов становится много, почему-то некоторые из них периодически падают. Тестировщики уже не очень рады. Нужно сидеть и разбираться в причинах. А баги все равно пролезают. И, вероятно, даже находятся на QA окружении путем ручного (может, даже monkey) тестирования.

Третья степень — все начинают ходить на конференции про Selenium (ничего не имею против этих конференций), узнавать как бороться с Flaky тестами, пробовать различные решения. Пускать тесты в параллель.

Четвертая степень — строить целые суперархитектуры по запуску 500 e2e тестов на 50 агентах, чтобы все летало быстро, аж за 10 минут (я тут утрирую, конечно). И все равно баги есть.

Пятая степень — я назову ее недостижимой. Приходит осознание того, что бОльшая часть e2e тестов не нужна. Нужны другие тесты, которых никто никогда не писал. Например, компонентные тесты на back-end или они же на UI. А может, не они, может, системные тесты? А может, и тесты на верстку? А может, Ваш, {username} вариант?

Безусловно есть проекты, где все сделано «правильно». Но зачастую встречается проблема непонимания того, что нужно протестировать. Только правильное понимание может сохранить ваше время и финансы. И более того, улучшить качество продукта.

— Как влияет на инструменты и подходы тестировщиков развитие средств разработки и подходов к созданию кода? Что из новшеств облегчает 
unit-тестирование (например, представление методов в виде лямбда-функций)?

Marc Philipp: Новые инструменты стараются облегчить жизнь разработчикам, предоставляя им большую гибкость. Однако, в конце концов, я считаю, что не имеет значения, представляете ли вы свои тесты как методы или в виде лямбда-функций. Понять, что тестировать и как тестировать, — это самая сложная часть.

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

Что облегчает тестирование — странный вопрос. Думаю, что технологии не могут сильно облегчить жизнь. Так как, чтобы использовать что-то новое (технология, инструмент), его нужно изучить всей команде, принять какую-ту «полиси», code style. Это в перспективе может, конечно, облегчить жизнь, но на коротких дистанциях не очень полезно, так как трудозатратно, имхо.

Кстати, вариант перехода на Kotlin (если мы говорим про Java тесты) – может и неплохая идея. Я в своей практике пока не пробовал.

Касательно новшеств языка (лямбды и прочие полезности) — это все хорошо, конечно, но мне трудно сказать, насколько они облегчают жизнь, так как нужно это измерить. Я не измерял. Но только не записывайте меня в противники прогресса, я считаю, что практика по изучению/использованию чего-то нового должна присутствовать всегда. Это обычная continuos improvement история.

— Насколько вы покрываете unit-тестами ваши продакшн проекты? Стоит ли тратить время на 100% покрытие?

Marc Philipp: В зависимости от языка программирования и фреймворков, которые вы используете, в проекте может быть некоторый шаблонный код, который не содержит никакой логики. Но кроме таких кусков, на мой взгляд, вы должны написать unit-тесты для всего вашего кода. Таким образом, я бы посоветовал охват более 90%.

Всеволод Брекелов: В проектах, в которых мне приходилось работать, чаще всего разработчики стараются довести тесты до покрытия в 90%. Стоит ли тратить время – обычно решается менеджерами. Я не менеджер, но по мне юнит тесты – это очень хорошая практика, 100% покрытие хорошо иметь, когда есть на это ресурсы.

Главное, надо помнить, что 100% покрытие, к сожалению, не гарантирует, что у вас нет багов.

Из того, что кажется более полезным, чем гонка с 90% до 100% coverage, — это написание мутационных тестов. Ничего не скажу нового относительно статьи 2012 года. Но на практике не очень часто видел, чтобы применяли этот подход (да и сам я тоже, каюсь). Так может быть пора начинать?

— Как тестовые фреймворки помогают с unit-тестами? Какую часть работ они берут на себя? Чего не стоит ждать при использовании фреймфорков?

Marc Philipp: Хороший фреймворк позволяет очень быстро и легко писать простые unit-тесты и в то же время содержать мощные механизмы для проведения более сложных тестов. Например, он должен помочь вам подготовить тестовые данные и предоставить точки расширения, которые позволят вам повторно использовать одну и ту же логику во многих тестах. Но никакой фреймворк не решит за вас, что и как тестировать. Также он не может волшебным образом улучшить ваш проект, чтобы сделать его хорошо тестируемым.

— Какие элементы кода сложнее всего поддаются unit-тестированию? Как решается эта проблема у вас?

Всеволод Брекелов: Чем больше зависимостей — тем больше рутины, тем сложнее писать юнит тест. А в целом, не вижу каких-то особенных проблем, если честно. Хотя на тему unit тестов написано большое количество книг, из которых я ни одну не прочитал до конца. Может, поэтому я не обременен проблемами.

Например, сложно написать unit-тест, когда, скажем, конструктор объекта содержит в себе вермишели кода, но тогда можно советовать товарищам прочитать книжки,
например и ввести code review практику.

Что касается JavaScript кода, то там можно встретиться с различными сложностями и внезапностями (да, я очень люблю JavaScript), скорее связанными с используемым фреймворком, например, работа с digest’ом. Я использовал только AngularJS/Angular2/Angular4. Несмотря на старания команды Angular сделать удобно-тестируемый фреймворк, все равно периодически сталкиваешься с проблемами, которые безусловно имеют решения, мы ведь инженеры.

Обсудить в форуме.

Как работать с unittest на языке Python делаем unit тест

Автор статьи: admin

В этой статье мы разберём как работать с unittest в Python, думаю всем будет очень полезно и интересно.

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

Подготовка проекта:

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

В начале создаём два файла, «calc.py», в нём мы будем хранить функции для вычислений калькулятора, и «test.py», в нём будет происходить всё тестирование.

Давайте поострим что будет в «calc.py»:

Как видите у нас тут несколько функций, которые отвечают за складывание, вычитание, умножение и деление соответственно, их и будем тестировать, так же можете добавить их в калькулятор, но это не обязательно для теста.

Как работать с unittest в Python:

Теперь перейдём к самому тестированию, тесты будем писать в «test.py», вот что должно быть в нём:

Как видите в самом начале файла мы импортируем библиотеку unittest и наш файл «calc. py» где находиться все функции для работы калькулятора.

Потом создаём класс Test, который унаследуем от класса TestCase, это пожалуй самое важное что нужно делать в в классе для тестирования.

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

Каждый метод использует метод assertEqual(), который в качестве параметров принимает в себя функцию которую нужно проверить, и значение которая она должна вернуть, если она возвращает другое значение, то при тестирование появится ошибка, таким образом и делаем unit тест в Python.

Последние что мы делаем, это код для запуска программы, внутри условия if __name__ == '__main__', мы запускаем unittest.

Для запуска тестирования введите команду в консоль:

Вот что должно появиться в консоли:

Как видите у нас всё запустилось, и работает, если же была ошибка, то он бы это вывел.

Тестирование классов:

Не много стоит упомянуть про тестирование классов, по сути всё точно так же, как и с обычными функциями, нужно только объявить класс, сделать это можно таким образом:

То есть объявлять класс нужно во методе setUp(), по сути он работает как конструктор, поэтому его стоит знать.

Дальше для получения метода класса нужно сделать так:

Ну и конечно это всё делается внутри класса для тестирования.

Другие тесты:

Так же очень важно упомянуть другие методы, которые тестируют код, вот их список:

• assertNotEqual() — Тоже самое что и assertEqual(), но проверяет не равенство;
• assertTrue() — Смотрит чтобы функция возвращала True;
• assertFalse() — Смотрит чтобы функция возвращала False;
• assertIs(a, b) — a есть b;
• assertIsNot(a, b) — a не есть b;
• assertCountEqual(a, b) — a и b содержат те же элементы в одинаковых количествах, но порядок не важен;

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

Вывод:

В этой статье мы кратко разобрали как работать с unittest на языке программирования Python, думаю вам было интересно.

Также если вас заинтересовала библиотека, то посмотрите официальную документацию по ней.

Подписываетесь на соц-сети:

Оценка:

(Пока оценок нет)

Загрузка…

Также рекомендую:

Добавление юнит-тестирования в проект Django

Автор выбрал фонд Open Internet/Free Speech для получения пожертвования в рамках программы Write for DOnations.

Введение

Практически невозможно создавать веб-сайты, которые будут идеально работать сразу без каких-либо ошибок. По этой причине вы должны тестировать ваше веб-приложение, чтобы находить эти ошибки и упреждающе работать с ними. Чтобы повысить эффективность тестирования, очень часто используется разбивка тестов на модули, которые проверяют конкретный функционал веб-приложения. Эта практика называется юнит-тестированием. Это упрощает обнаружение ошибок, поскольку тесты фокусируются на небольших частях (юнитах) вашего проекта, никак не затрагивая другие его части.

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

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

Предварительные требования

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

Шаг 1 — Добавление набора тестов для вашего приложения Django

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

Если вы ознакомились с серией обучающих материалов по разработке Django, у вас в распоряжении должно быть приложение Django с именем blogsite​​​.

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

cd ~/my_blog_app
. env/bin/activate

Затем перейдите в каталог приложения blogsite, в папку, которая содержит файлы models.py и views.py​​​, а затем создайте новую папку с именем tests:

cd ~/my_blog_app/blog/blogsite
mkdir tests

Далее необходимо превратить эту папку в пакет Python, добавив файл __init__. py:

cd ~/my_blog_app/blog/blogsite/tests
touch __init__.py

Теперь вы должны добавить файл для тестирования ваших моделей и другой файл для тестирования представлений:

touch test_models.py
touch test_views.py

В заключение вы создадите пустой тест-кейс в файле test_models.py: Вам нужно будет импортировать класс TestCase Django и сделать его родительским классом для вашего класса тест-кейса. В дальнейшем вы сможете добавить в этот тест-кейс методы для тестирования логики в ваших моделях. Откройте файл test_models.py:

Теперь добавьте в файл следующий код:

~/my_blog_app/blog/blogsite/tests/test_models.py

from django.test import TestCase

class ModelsTestCase(TestCase):
    pass

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

Шаг 2 — Тестирование кода Python

На этом шаге вы протестируете логику кода в файле models.py. В частности, вы должны будете протестировать метод save модели Post, чтобы убедиться, что при вызове он создает корректный слаг для тайтла поста.

Давайте начнем с изучения кода, который уже находится в файле models.py для метода save модели Post:

cd ~/my_blog_app/blog/blogsite
nano models.py

Вы увидите следующее:

~/my_blog_app/blog/blogsite/models.py

class Post(models.Model):
    ...
    def save(self, *args, **kwargs):
        if not self.slug:
            self.slug = slugify(self.title)
        super(Post, self).save(*args, **kwargs)
    ...

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

Закройте файл.

Чтобы протестировать это, вернитесь к файлу test_models.py:

Затем обновите его содержимое, добавив код в выделенные части:

~/my_blog_app/blog/blogsite/tests/test_models.py

from django.test import TestCase
from django.template.defaultfilters import slugify
from blogsite.models import Post


class ModelsTestCase(TestCase):
    def test_post_has_slug(self):
        """Posts are given slugs correctly when saving"""
        post = Post.objects.create(title="My first post")

        post.author = "John Doe"
        post.save()
        self.assertEqual(post.slug, slugify(post.title))

Этот новый метод test_post_has_slug создает новый пост с именем "My first post", а затем указывает для поста автора и сохраняет пост. После этого, используя метод assertEqual из модуля unittest Python, он проверяет корректность слага для поста. Метод assertEqual проверяет, равны ли два переданных ему аргумента, что определяется оператором "==", и генерирует ошибку в противном случае.

Сохраните и закройте test_models.py.

Это пример того, что можно протестировать. Чем больше логики вы будете добавлять в ваш проект, тем больше тестов вам потребуется. Если вы добавите в метод save дополнительную логику или создадите новые методы для модели Post, вам нужно будет добавить сюда дополнительные тесты. Вы можете добавить их в метод test_post_has_slug или создать новые методы тестирования, но их имена должны начинаться с test.

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

Шаг 3 — Использование тестового клиента Django

На этом шаге вы напишете тест-кейс, который тестирует представление с помощью тестового клиента Django. Тестовый клиент — это класс Python, который действует как шаблонный браузер, позволяя вам тестировать ваши представления и взаимодействовать с приложением Django таким же образом, как это делал бы пользователь. Вы можете получить доступ к тестовому клиенту, сославшись на self.client в ваших тестовых методах. Давайте, например, создадим тест-кейс в test_views.py. Откройте файл test_views.py​​​:

Затем добавьте следующее:

~/my_blog_app/blog/blogsite/tests/test_views.py

from django.test import TestCase


class ViewsTestCase(TestCase):
    def test_index_loads_properly(self):
        """The index page loads properly"""
        response = self.client.get('your_server_ip:8000')
        self.assertEqual(response.status_code, 200)

ViewsTestCase содержит метод test_index_loads_properly, который использует тестовый клиент Django для посещения стартовой страницы веб-сайта (http://your_server_ip:8000, где your_server_ip — это IP-адрес сервера, который вы используете). Затем тестовый метод проверяет, содержит ли ответ код состояния 200, который означает, что страница отправляет ответ без ошибок. В результате вы можете быть уверены, что при посещении страницы пользователем она также не будет генерировать ошибки.

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

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

Шаг 4 — Запуск тестов

Теперь, когда вы завершили сборку набора тестов для проекта, пришло время запустить эти тесты и посмотреть их результаты. Чтобы запустить тесты, перейдите в папку blog (содержащую файл manage.py приложения):

Запустите их с помощью следующей команды:

Вы увидите примерно следующий вывод в вашем терминале:

Output
Creating test database for alias 'default'. ..
System check identified no issues (0 silenced).
..
----------------------------------------------------------------------
Ran 2 tests in 0.007s

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

Этот вывод содержит две точки .., каждая из которых отображает выполненный тест-кейс. Теперь вы можете изменить test_views.py, чтобы вызвать падение теста. Сначала откройте файл с помощью следующей команды:

Затем измените выделенный код на следующий:

~/my_blog_app/blog/blogsite/tests/test_views.py

from django.test import TestCase


class ViewsTestCase(TestCase):
    def test_index_loads_properly(self):
        """The index page loads properly"""
        response = self.client.get('your_server_ip:8000')
        self.assertEqual(response.status_code, 404)

Здесь вы изменили код состояния с 200 на 404. Теперь снова запустите тест из каталога с файлом manage.py:

Вывод должен выглядеть так:

Output
Creating test database for alias 'default'. ..
System check identified no issues (0 silenced).
.F
======================================================================
FAIL: test_index_loads_properly (blogsite.tests.test_views.ViewsTestCase)
The index page loads properly
----------------------------------------------------------------------
Traceback (most recent call last):
  File "~/my_blog_app/blog/blogsite/tests/test_views.py", line 8, in test_index_loads_properly
    self.assertEqual(response.status_code, 404)
AssertionError: 200 != 404

----------------------------------------------------------------------
Ran 2 tests in 0.007s

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

Вы увидите сообщение, содержащее описание ошибки, указывающее скрипт, тест-кейс и метод, который не был выполнен. Также оно сообщает причину ошибки, в данном случае код состояния не равен 404, в форме сообщения AssertionError: 200 ! = 404. AssertionError здесь возникает в выделенной строке кода в файле test_views. py:

~/my_blog_app/blog/blogsite/tests/test_views.py

from django.test import TestCase


class ViewsTestCase(TestCase):
    def test_index_loads_properly(self):
        """The index page loads properly"""
        response = self.client.get('your_server_ip:8000')
        self.assertEqual(response.status_code, 404)

Она указывает, что утверждение является ложным, т. е. код состояния ответа (200) не соответсвует ожидаемому результату (404). Теперь вы можете видеть, что две точки .., идущие перед сообщением об ошибке, теперь превратились в . F, что говорит о том, что первый тест-кейс был пройден успешно, а второй — нет.

Заключение

В этом руководстве вы создали набор тестов в вашем проекте Django, добавили тест-кейсы для тестирования логики модели и представления,узнали, как запускать тесты, и проанализировали вывод теста. В качестве следующего шага вы можете создать новые тестовые скрипты для кода Python в других файлах помимо models. py и views.py.

Ниже представлено несколько статей, которые могут оказаться полезными при создании и тестировании сайтов с помощью Django:

Также вы можете найти на нашей странице материалов по теме Django другие руководства и проекты.

Модульное тестирование на языке C: инструменты и условные обозначения

В настоящее время в комментариях разрешены следующие HTML-теги:

Одиночные теги

Эти теги можно использовать отдельно, без конечных тегов.


Определяет одинарный разрыв строки

Определяет горизонтальную линию

Соответствующие теги

Требуется конечный тег, например курсив

Определяет привязку

Определяет полужирный текст

Определяет большой текст

Определяет длинную цитату

Определяет таблицу caption

Определяет цитату

Определяет текст компьютерного кода

Определяет выделенный текст

Определяет границу вокруг элементов в форме

Это заголовок 1

Это заголовок 2

Это заголовок 3

Это заголовок 4

Это заголовок 5

Это заголовок 6

Определяет курсивный текст

Определяет абзац

  Определяет предварительно отформатированный текст 
 
  < q>  Определяет короткую цитату 
 
    Определяет образец текста компьютерного кода 
 
    Определяет мелкий текст 
 
    Определяет раздел в документе 
 
    Определяет зачеркнутый текст 
 
    Определяет зачеркнутый текст 
 
    Определяет усиленный текст 
 
    Определяет подписанный текст 
 
    Определяет надстрочный текст 
 26   подчеркнутый текст 

    
 Модульное тестирование с C ++: как и почему 
 
 Почему модульное тестирование с C ++ не так распространено, как с Java, C # и Python? 
 
  Не знаю.  Я надеялся, что это так. 
 
 Если вы разрабатываете на C ++, вы уже должны писать тесты. Нет причин не делать этого, и есть много причин, по которым вам нужно начать сегодня. 
 
 Что такое модульное тестирование? 
 
 Прежде чем я расскажу, почему и как проводить модульное тестирование с помощью C ++, давайте определимся, о чем мы говорим. 
 
 Модульное тестирование означает написание кода, который проверяет отдельные части или  модулей,  приложения или библиотеки. Блок   - это самая маленькая тестируемая часть приложения.Модульные тесты оценивают код в изоляции .  
 
 В C ++ это означает написание тестов для методов или функций. Тесты проверяют код только внутри одного объекта. Они не полагаются на внешние ресурсы, такие как базы данных, веб-серверы или брокеры сообщений. 
 
 Для этого обсуждения я предполагаю, что вы выполняете свои модульные тесты как часть сборки или, что еще лучше, системы непрерывной интеграции.  
 
 Почему модульный тест с C ++? 
 
 
 Находите глупые ошибки в начале  
 
 Мы все пишем глупые ошибки.Мы создаем отдельные ошибки, определяем некорректные константы, портим алгоритм или пишем одну из тех, «о чем, черт возьми, я думал?» ошибки каждый день. Мы всего лишь люди. Даже мы, разработчики C ++, несмотря на то, что эти ребята из C # шепчутся в столовой. 
 
 Без модульных тестов мы не обнаружим эти ошибки, пока не дойдем до интеграционного тестирования или, что еще хуже, QA. Но так же вероятно, что мы не найдем их до более поздней стадии производства. 
 
 Итак, модульные тесты действуют как подстраховка. Потратив время на написание проверок для каждого метода или функции по мере их написания, мы отлавливаем глупые ошибки  при их создании. 
 
 
 Избегайте регрессов  
 
 Не все ошибки глупы. Некоторые ошибки довольно умны. Мы называем их  регрессиями .  Если вы живете здесь более нескольких лет, вы видели одно из них. 
 
 Ваша система давно работает в производственной среде, но вам необходимо добавить новую функцию или устранить недостаток. Итак, вы изменяете код и выпускаете новую версию, а что-то еще ломается. Если повезет, в этом легко разобраться. Если нет, отмените планы на выходные.
 
 Ваша первая линия защиты от регрессий - модульные тесты. Создание целевых подпрограмм, которые проверяют дискретное поведение, а затем их запуск при каждой сборке, помогает гарантировать, что новая функция не сопровождается новой ошибкой. 
 
 
 Получить раннюю обратную связь  
 
 Модульное тестирование с C ++ дает вам раннюю обратную связь. Иногда говорят, что вы не стали причиной новой регрессии. В других случаях дело в том, делает ли ваш новый код то, что вы думаете. 
 
 Ранняя обратная связь означает уверенность.Без модульных тестов вы не знаете, работает ли то, что вы делаете.  Прекрасно писать код, который компилируется с первого раза. Еще лучше - писать код, который сразу делает то, что вы хотите. 
 
 
 Лучший дизайн  
 
 Написание модульных тестов для кода означает написание кода, который может быть разбит на отдельные блоки. Тестируемый код является модульным, потому что дискретно тестируемые модули слабо связаны. 
 
 Если эта причина модульного тестирования в сочетании с предыдущей выглядит как реклама разработки через тестирование (TDD), то это потому, что это так.TDD работает, и это повод начать использовать модульное тестирование с C ++. Гибкие системы связаны с такими языками, как Java, Ruby и C #. Это из-за языков или связанных с ними практик? 
 
 Нет. Нет никаких причин, по которым вы не можете реализовать быстро развивающуюся архитектуру с помощью C ++. 
 
 Создание встроенной документации 
 
 Поднимите руку, если доверяете комментариям. 
 
 Да, я так не думал.  Даже ваши комментарии могут стать непонятными или совершенно неправильными через несколько месяцев.
 
 Но вы когда-нибудь заглядывали в модульные тесты, чтобы увидеть, как что-то работает? Вы вздыхаете с облегчением, когда проверяете код и находите тесты? Тесты не лгут. Иногда лучший способ понять, как работает код, - это увидеть его в действии. 
 
 Как выполнить модульное тестирование с помощью C ++ 
 
 Итак, теперь вы продаете модульное тестирование, не так ли? Тогда перейдем к делу. 
 
 
 Выберите тестера  
 
 Для модульного тестирования с C ++ требуется средство запуска тестов. Мы пишем тесты как функции, а затем связываем функции в двоичный файл, который сборка выполняет как цель тестирования.Итак, нам нужна основная функция, которая умеет запускать тесты, проверять результаты и печатать отчет. 
 
 Слишком много средств запуска тестов и фреймворков для модульного тестирования C ++, чтобы перечислить их здесь.  Я перечислю несколько наиболее распространенных. 
 
 Visual Studio поставляется с Microsoft Unit Testing Framework для C ++. Вы можете создать проект со встроенным средством запуска тестов и добавить тестовые классы несколькими щелчками мыши. 
 
 Google Test - самый известный кросс-платформенный инструмент запуска тестов для C ++.Он распространяется как исходный код. Итак, вы должны создать его для своей среды или включить в CMake как зависимость от поставщика. Он поставляется с имитационной библиотекой и, в отличие от бегуна от Microsoft, является программным обеспечением с открытым исходным кодом. 
 
 Другими исполнителями тестов C ++ являются CppUnit и CxxTest. 
 
 
 Выберите фреймворк для имитации  
 
 Теперь вы можете запускать тесты. Значит, вам нужно их написать. Ключом к написанию эффективных тестов является выбор отдельного модуля, а затем изолированная проверка его функциональности.Если тест не проходит и причина сбоя не очевидна, тестируемый блок не изолирован.  
 
 В зависимости от того, что мы тестируем, нам может потребоваться фиктивная версия. Мокинг - это создание объекта, который имитирует поведение другого объекта. Например, если мы тестируем объект, который взаимодействует с API обмена сообщениями, мы будем имитировать соединение обмена сообщениями, а не писать тест, который требует подключения к брокеру обмена сообщениями. 
 Isolator ++ от Typemock 
 - это имитирующая библиотека C ++ для Windows и Linux.С его помощью вы можете подделать любой класс или шаблон и любой метод, не изменяя существующий код. 
 
 Проект Google Test связывает Google Mock с средством запуска тестов. Вы можете использовать его для имитации классов и шаблонов C ++, но у библиотеки есть ограничения, которые затрудняют работу с конкретными и бесплатными функциями. 
 
 Вы можете прочитать сравнение Isolator ++ и Google Mock здесь. 
 
 
 Использование внедрения зависимостей  
 
 Если вы пишете новый код или можете изменить устаревший код, внедрение зависимостей (DI) - ваш друг. Хотя вы можете связать DI только с Java, он также доступен в C ++. В разработке даже есть библиотека Boost. 
 
 Но для использования DI не требуется фреймворк. Если вы еще не хотите использовать экспериментальную библиотеку или переходить на новую версию C ++, вы все равно можете использовать DI в своем коде C ++. 
 
 Самая простая форма DI - внедрение конструктора .  Фаулер описывает это в статье, на которую я ссылался выше, с использованием фреймворка для Java, но достаточно легко развернуть свою собственную, если вы не хотите добавлять новую внешнюю зависимость.
 
 DI означает отделение создания объекта от его использования. Этот шаблон позволяет легко заменить реализацию службы на новую. Фаулер даже использует термин  plugin  для описания внедренных объектов в своем сообщении. 
 
 Но DI также упрощает тестирование вашего кода. Вы можете передать подделку объекту при инициализации, а затем использовать ее для наблюдения за тестируемым объектом.  Внедрение зависимостей упрощает изоляцию объектов для проверки. 
 
 Если вы работаете со сложным и тесно связанным устаревшим кодом, имитирующая среда, такая как Isolator ++, может помочь вам в создании тестов.Платформа идеально подходит для добавления тестов в унаследованный код. Но написание кода с использованием такого шаблона, как DI, всегда упростит задачу, и рефакторинг этого устаревшего кода тоже может быть хорошей идеей. 
 
 
 Запись тестов AAA  
 
 Тесты, которые трудно расшифровать, почти так же плохи, как и отсутствие тестов. (Но только почти.) 
 
 Как и чистый код, есть чистые тесты. Чистые тесты легко читать и фокусируются на одном элементе поведения. 
 
 Один из способов убедиться, что ваши тесты просты для понимания, - это реализовать три A: Arrange, Act и Assert.Если вы структурируете свои тесты с учетом этого, они будут последовательными и всеобъемлющими. 
 
  Arrange  собирает требования к тесту и подготавливает их к тесту.  Здесь вы создаете объект для тестирования и устанавливаете все необходимые предварительные условия. Также здесь вы создаете свои макеты. 
 
  Акт  - это сама тестовая операция. Обычно это короткая часть теста. В идеале это место, где вы вызываете одну функцию или метод. 
 
  Утверждение  подтверждает, что тест прошел успешно.Здесь вы можете увидеть список из  утверждений , которые проверяют состояние различных переменных. 
 
 Мандат модульного тестирования с помощью C ++ 
 
 Нет смысла писать код C ++ без модульных тестов. Все шаблоны и практики, связанные с тестированием, возможны с этим языком, потому что, как мы все знаем, вы ничего не можете сделать с другим языком, чего вы не можете сделать с C ++. Большинство других языков реализованы на C ++ под оболочкой. 
 
 Итак, приступим сегодня же! Isolator ++ поддерживает C ++ в Windows и Linux и содержит функции, которые помогут вам сразу приступить к модульному тестированию. Загрузите пробную лицензию сегодня. 
 
 Статические функции модульного тестирования в C 
 

В коде C раздражает то, что существует множество функций, которые не могут быть протестированы какой-либо внешней структурой, в частности, все, что объявлено как  static . Любая более крупная кодовая база будет содержать сотни этих функций, многие из которых короткие и достаточно автономные, но достаточно сложные, чтобы не доверять им только по внешнему виду. Но поскольку они  static , я не могу получить к ним доступ извне (и "снаружи" здесь определяется как "не в том же файле").
 

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

 

В любом случае, на этой неделе я наконец нашел правильную комбинацию приемов, которая упростит тестирование функций  static , и это:
 
 
 
  # включить  исходный файл в тестовый код.
 
 Смоделируйте любые вспомогательные функции, которые могут понадобиться для обмана вызываемых функций 
 
 Указать компоновщику игнорировать неразрешенные символы 
 
И бум, вы можете написать тестовые примеры только для тестирования одного файла в вашем исходном дереве. И без каких-либо модификаций самого исходного кода.


 
 Более подробная запись доступна в этом репозитории на github.

 
 

Для нетерпеливых фрагмент мезона для вымышленного исходного файла  example.c  будет выглядеть так:
 
 
test ('тест-пример',
     исполняемый файл ('test-example',
                'пример.c ',' test-example.c ',
                зависимости: [dep_ext_library],
                link_args: ['-Wl, - unresolved-symbols = ignore-all',
                            '-Wl, -zmuldefs',
                            '-no-pie'],
                установить: false),
)
 
 Нет никаких ограничений на то, какой набор тестов вы можете использовать. Я начал добавлять в libinput несколько тестовых примеров, основанных на этом подходе, и пока он работает хорошо. Если у вас есть лучший подход или улучшения, я все слышу.
 Начало работы с модульным тестированием C ++ - вспомогательный код 
 Я «живу» в мире C ++ с самого начала (своей карьеры).Но в последнее время я заметил рост интереса к модульному тестированию C ++ и даже поговорил об этом в NDC Oslo. Но это не просто тестирование устаревшего кода C ++ 10-летней давности - я считаю, что C ++ - самый инновационный язык с точки зрения модульного тестирования. Так что, если вы не разработчик C ++ (и до сих пор пережили этот пост), вам следует проверить некоторые нововведения в области модульного тестирования C ++.
 Поскольку мне не удалось найти ни одного, я решил составить список ресурсов для разработчиков C ++, которые хотят больше узнать о TDD и модульном тестировании, основываясь на моем собственном опыте и предпочтениях.
 Книги 
 Я люблю читать книги, я знаю, что могу быть частью вымирающей породы, но я думаю, что они содержат знания организованным образом, которые отсутствуют в других ресурсах (включая нынешнюю среду). В области модульного тестирования C ++ есть две книги, которые я прочитал много лет назад, но все еще считаю полезными в повседневной работе:
 Современное программирование на C ++ с помощью разработки через тестирование (код лучше, лучше спать)
 Вы должны полюбить эту книгу. У него отличное название и хорошее содержание.Он требует от руки показать вам, как TDD ваш код - шаг за шагом (поскольку TDD следует практиковать). В книге основное внимание уделяется GTest, а в некоторых последующих главах используется CppUnit.
 Хотя я не согласен со всем в этой книге, я счел ее полезной для всех, кто хочет начать изучение TDD и модульного тестирования в мире C ++. Имейте в виду, что за время, прошедшее с момента публикации этой книги, все немного изменилось, но основы остались прежними. Я написал рецензию на эту книгу три года назад - и до сих пор ее поддерживаю.
 Эффективная работа с устаревшим кодом
 Эта книга - неподвластная времени классика, и она много раз помогала мне решать сложные, трудные и разочаровывающие проблемы. Узнав о модульном тестировании и TDD, вы захотите применить свои новые возможности в реальном мире - и тогда вы должны прочитать эту книгу.
 Вам не обязательно быть разработчиком на C ++. I, но это помогает, поскольку некоторые примеры и методы написаны на C ++.
 Эта книга показывает, как модульное тестирование может спасти ваш код от медленной и мучительной смерти, и учит разработчиков, что делать, когда они сталкиваются с огромным, старым, сложным и запутанным устаревшим кодом.
 Каркасы 
 Чтобы начать работу, вам понадобится хорошая среда модульного тестирования и, вероятно, хорошая среда фиксации. Хорошая новость заключается в том, что существует множество стилей на выбор с множеством инновационных возможностей, выходящих за рамки классических стилей фреймворка модульного тестирования. Я должен признаться, что не использовал все возможные фреймворки для модульного тестирования, но я использовал их довольно много - и следующий список составлен с использованием только моего (неполного) опыта
 Фреймворки для модульного тестирования 
 GTest / Gmock - эта мощная пара де-факто была стандартом модульного тестирования C ++. Фактически, долгое время GMock был единственным издевательским фреймворком в мире C ++. Преимущество в том, что если у вас есть GMock, вы получаете полностью интегрированный GTest в том же пакете. Обратной стороной является то, что вам нужно собрать GTest / GMock, используя точную конфигурацию в качестве проекта, который вы пытаетесь протестировать, что может быть проблемой.
 Catch - это мой новый любимый фреймворк для модульного тестирования (не только на C ++). Развертывание осуществляется путем включения одного файла заголовка в тестовый проект, и все готово.У Catch есть много интересных функций - одно мощное утверждение, строки для имен тестов и замечательная функция, называемая «разделы» - вы можете узнать больше об этом в сообщении блога, которое я написал: «Catch - мультипарадигмальная автоматизированная среда тестирования для C ++» . Catch оказал такое влияние благодаря своим простым, но мощным возможностям, которые использовались в нескольких фреймворках C ++, таких как DocTest, и «поймать, как фреймворк модульного тестирования C ++» становится способом категоризации фреймворка точно так же, как «фреймворк тестирования xUnit». сейчас же.
 Mettle - много хороших идей в этом фреймворке, который немного отличается от других. Мне нравятся утверждения (полная настройка) и другой синтаксис, который он приносит с собой. Я думаю, что это та структура, которая поможет нам лучше понять и использовать модульное тестирование.
 Boost.Test - часть библиотеки boost, используется в некоторых проектах. У меня не было много времени, чтобы использовать его, но я нашел его слишком многословным, но я хотел бы попробовать еще раз, прежде чем принять решение.
 Мокинг рамок 
 Долгое время GMock использовался как фреймворк для имитации C ++.Он связан с GTest и для громких криков - его создал всемогущий Google.
 Сегодня есть и другие варианты, такие как Trompeloeil, который развертывается путем включения одного файла заголовка и имеет синтаксис, который мне нравится использовать. и FakeIt, классная, удивительная библиотека, которая помогает разработчикам писать поддельные объекты с очень минимальным кодом в синтаксисе, который может быть вам знаком, если вы когда-либо использовали Mockito (Java) или любую другую платформу имитации . NET. Кроме того, есть HippoMocks - хотя я еще не пробовал его в клиентской среде, кажется, что разработчики C ++ (включая меня) могут захотеть изучить еще один вариант.
 Если вы хотите увидеть синтаксис каждой проверки этого репозитория на GitHub, и вам следует проверить запись моего сеанса NDC в Осло: Модульное тестирование C ++ - хорошее, плохое и уродливое.
 Другие ресурсы 
 Конференции 
 Есть много хороших разговоров о модульном тестировании C ++, и я хотел бы увидеть их все - или, по крайней мере, знать обо всех из них, если вы знаете запись, которую я забыл упомянуть - пожалуйста, дайте мне знать в разделе комментариев.
  Мои сеансы модульного тестирования C ++ / тестирования устаревшего кода C ++ можно найти в разделе записи этого блога.
 Да, это снова Catch, - объяснил его создатель Фил Нэш (из Meeting C ++):
 
 Еще одна сессия от создателя фреймворка:
 
 Онлайн-курсы 
 Курсов по модульному тестированию C ++ не так много (читай: ни одного, о котором я знаю), поэтому год назад я решил исправить это, записав два курса для Pluralsight:
 Мне понравилось создавать эти курсы, и я надеюсь, что другие разработчики сочтут их полезными.
 Это все? 
 Это ресурс, который, как я думал, будет полезен разработчикам на C ++, которые начинают модульное тестирование (TDD) своего кода и не знают, с чего начать. Я уверен, что есть и другие полезные ресурсы, о которых я хотел бы узнать. Так что, если я забыл или, что более вероятно, не знал о классной библиотеке, онлайн-курсе или гуру - просто дайте мне знать.
 А пока - счастливого кодирования…
 Нравится: 
 Нравится Загрузка . ..
  Опубликовано 
  10 августа 2017 г.   29 мая 2018 г. 
Отчетность по модульным тестам
 C ++ (MS Unit Test Framework для C ++) - SonarQube 
 Информация, которую необходимо предоставить (в формате Markdown):
, какие версии вы используете (SonarQube, Scanner, Plugin и любое соответствующее расширение)
 Разработчик SonarQube 8.4.1, CFamily 6.11.0
 Visual Studio Enterprise 2019
 Сервер Azure DevOps 2019
 чего вы пытаетесь достичь 
 Сообщайте модульные тесты и покрытие кода в SonarQube
 Visual Studio из коробки поддерживает следующие платформы тестирования C ++:
  Microsoft Unit Testing Framework для C ++ 
 Google Test
 Boost.Test
 CTest
 Поскольку мы использовали предыдущие версии Visual Studio, мы используем фреймворк Microsoft. 
 Я запустил тесты и наконец преобразовал покрытие кода. Теперь я получаю покрытие линии и процент покрытия. Чего еще не хватает, так это количества юнит-тестов.
 Я читал, что SonarQube CFamily поддерживает только CppUnit. Это все еще актуально? Новые фреймворки не поддерживаются? Есть ли способ преобразовать результаты наших тестов в формат CppUnit, который читает SonarQube?
 что вы пытались до сих пор для достижения этого
 Запустить тесты и преобразовать покрытие кода.
 Сообщается о
 модульных тестах в Azure DevOps Server
  # Подготовка анализа SonarQube
      - задача: sonarsource.sonarqube.15B84CA1-B62F-4A2A-A403-89B77A063157.SonarQubePrepare@4
        displayName: 'Подготовить анализ на SonarQube'
        входы:
          SonarQube: Sonarqube
          projectKey: CppPart
          projectVersion: '$ (Build.BuildNumber)'
          # для смешанного решения C ++ / C # необходимо использовать `SonarScanner for MSBuild`!
          extraProperties: |
            сонар. projectDescription = Часть C ++
            sonar.exclusions = ** / *. java
            sonar.projectBaseDir = $ (SrcDir)
            sonar.cfamily.build-wrapper-output = $ (SonarOutDir)
            sonar.cfamily.threads = 4
            sonar.cfamily.cache.enabled = true
            sonar.cfamily.cache.path = $ (Agent.WorkFolder) / _ Кэш
            sonar.cfamily.vscoveragexml.reportsPath = $ (Common.TestResultsDirectory) /codeCoverage.xml

      # Построить решение C ++
      - задача: petergroenewegen.PeterGroenewegen-Xpirit-Vsts-Build-InlinePowershell.Xpirit-Vsts-Build-InlinePowershell.InlinePowershell@1
        displayName: 'Создать решение с оболочкой сборки'
        входы:
          Скрипт: |
            New-Item -Path $ (SonarOutDir) -ItemType каталог -Force
            Установить местоположение $ (SrcDir)
            $ (build_wrapper) --out-dir $ (SonarOutDir) "$ (msbuildPath) /MSBuild.exe" $ (SrcDir) /Solution.sln / t: Rebuild / nologo / nr: false / t: "Clean" / p: FullRelease = true / p: platform = $ (BuildPlatform) / p: configuration = $ (BuildConfiguration) / p: VisualStudioVersion = "16. 0 дюймов / м

      - задача: VSTest @ 2
        displayName: 'Тестовые сборки C ++ Модульные тесты'
        входы:
          testAssemblyVer2: '** / $ (BuildConfiguration) _ $ (BuildPlatform) / ** / * test * .dll'
          searchFolder: '$ (SrcDir)'
          vsTestVersion: toolsInstaller
          codeCoverageEnabled: false # это вызывает сбой vstest.console (неверный формат изображения)
          testRunTitle: 'Модульные тесты C ++'
          otherConsoleOptions: '/ платформа: x64 / Logger: trx / Enablecodecoverage'
          платформа: '$ (BuildPlatform)'
          конфигурация: '$ (BuildConfiguration)'

      - задача: petergroenewegen.PeterGroenewegen-Xpirit-Vsts-Build-InlinePowershell.Xpirit-Vsts-Build-InlinePowershell.InlinePowershell@1
        displayName: 'Конвертировать отчет о покрытии кода'
        входы:
          Скрипт: |
            Установить-расположение $ (Build.SourcesDirectory)
            & "$ (codeCoveragePath)" анализировать /output:$(Common.TestResultsDirectory)/codeCoverage. xml (Get-ChildItem TestResults / * / *. охват)
  
 5 лучших фреймворков модульного тестирования для автоматизации модульных тестов 
 Что такое модульное тестирование? 
 Модульное тестирование - это способ тестирования самого маленького фрагмента кода, называемого модулем, который может быть логически изолирован в системе.Модуль - это наименьшая тестируемая часть любого программного обеспечения, имеющая один или несколько входов и один выход. Каждый блок тестируется, чтобы убедиться, что программное обеспечение работает должным образом. Модульное тестирование в основном ориентировано на функциональную корректность автономных модулей. Найдите список из 5 лучших фреймворков модульного тестирования для автоматизации модульных тестов.
 Модульное тестирование - это тип тестирования программного обеспечения, при котором тестируются отдельные компоненты кода. Это необходимо для того, чтобы убедиться, что каждый блок работает должным образом. Модульное тестирование - это самая маленькая часть программного обеспечения, которую вы можете протестировать.Обычно это один или два входа, которые приводят к одному выходу.
 Существует два типа модульного тестирования: ручное и автоматическое. Автоматизированный метод обычно является предпочтительным, поскольку он экономит время и силы разработчика. Чтобы выполнить модульное тестирование, ваш разработчик должен написать понятный тестовый код для проверки конкретной функции на ожидаемый результат. Затем будут запущены тесты, и все ошибки или сбои, приведшие к ожидаемому результату, будут зарегистрированы.
 Разработчики могут просмотреть сводку и исправить блоки, не соответствующие установленному критерию.
 Фреймворк модульного тестирования для c # 
 NUnit - одна из самых популярных сред модульного тестирования C #.
 NUnit: 
 NUnit - это фреймворк для модульного тестирования, который принадлежит семейству xUnit и полностью написан на C #. Несколько фреймворков для модульного тестирования, которые заимствуют свой дизайн и функциональность из Smalltalk SUnit, вместе называются xUnit. Он обеспечивает поддержку всех языков .NET и служит той же цели, что и JUnit для Java. Это программное обеспечение с открытым исходным кодом, которое изначально было перенесено из JUnit.Текущий производственный выпуск - это версия 3, которая была полностью переписана, чтобы предложить множество новых функций.
 Фреймворки модульного тестирования для Java 
 Многие Java-разработчики хорошо разбираются в написании модульных тестов. Эти модульные тесты автоматически запускаются во время сборки с помощью инструментов непрерывной интеграции, таких как Jenkins или Team city. По мере того, как важность автоматизированного тестирования растет, все большее распространение получают фреймворки модульного тестирования, такие как JUnit.
 J Единица: 
 JUnit - это среда модульного тестирования  с открытым исходным кодом  для среды разработки, управляемой тестированием. Он поддерживает основную концепцию «сначала тестирование, затем кодирование». Эта структура специально разработана для языка программирования Java. При этом данные сначала проверяются, а затем вставляются в фрагмент кода. Это самый простой способ быстрого и легкого написания кода. Он также предлагает аннотацию для идентификации метода тестирования.
 TestNG: 
 TestNG - это среда автоматизации тестирования с открытым исходным кодом, специально разработанная для языка программирования Java. TestNG похож на JUnit и NUnit, но предлагает некоторые новые функции, которые делают его мощным и простым в использовании.TestNG поддерживает параллельное тестирование, а также предлагает поддержку аннотаций. TestNG имеет мощную модель выполнения с гибкими возможностями настройки тестов.
 Платформа модульного тестирования для C или C ++ 
 Фреймворк модульного тестирования для C или C ++, популярный среди разработчиков, - Embunit.
 Набережная: 
 Embunit - это среда модульного тестирования с открытым исходным кодом, предназначенная для программного обеспечения, написанного на C или C ++. Embunit разработан как инструмент модульного тестирования как для разработчиков, так и для тестировщиков программных приложений, написанных на C или C ++.В Embunit нет необходимости писать какой-либо код, тесты указываются в виде списка действий. Соответствующий исходный код для тестов создается автоматически.
 Фреймворк для модульного тестирования JavaScript 
 JavaScript - это «язык Интернета», который является причиной большого количества фреймворков автоматизации тестирования. Вот одна из самых популярных сред модульного тестирования для JavaScript.
 HtmlUnit: 
 HtmlUnit - это платформа для модульного тестирования  с открытым исходным кодом , которая поддерживает JavaScript и предоставляет такие функции графического интерфейса, как формы, ссылки, таблицы и т. Д.Он предлагает библиотеку Java с открытым исходным кодом, которая содержит браузер без графического интерфейса пользователя для программ Java. HtmlUnit использует движок JavaScript под названием Mozilla Rhino и поддерживает такие протоколы, как HTTP, HTTPS. Он также поддерживает файлы cookie, методы отправки, такие как GET, POST и прокси-сервер. Он используется для тестирования веб-приложений, которые используются в таких фреймворках, как JUnit и TestNG.
 Сводка 
 Перечисленные выше инструменты  модульного тестирования  помогают автоматизировать процесс модульного тестирования и улучшить результаты модульного тестирования.
 Присоединяйтесь к 60000+ подписчиков 
 Для последних блогов, отраслевых новостей и эксклюзивных советов.
 * Ваша электронная почта в безопасности с нами, мы также ненавидим спам
Модульное тестирование
 C с проверкой 
Когда я начал заниматься ИТ, несколько лет назад (+15), C был первым языком, который я выучил. Но это был не первый язык, который я освоил и развернул в производственной среде, а это ... удивительно Visual Basic 6.0. Однако, когда я выучил Си или любой другой язык в те старые и загадочные времена, Нодди уже занялся тестированием. Однако сейчас без тестов профессионально работать на любом языке невозможно. C - это низкоуровневый язык, но он по-прежнему неплох и имеет несколько интересных библиотек / фреймворков. Люди привыкли бояться C из-за отсутствия синтаксического сахара, но как только вы к нему привыкнете, это совсем не сложно. Сегодня я хочу показать, как можно выполнять модульное тестирование с помощью C. Я не буду показывать, как выполнять модульное тестирование с помощью C ++, а на самом деле с помощью C ANSI.Мы будем использовать Проверить библиотеку модульных тестов для C ANSI.
  Проверка установки в Ubuntu 
 В настоящее время я запускаю ubuntu 18.04 LTS на своем ноутбуке. Итак, прежде всего, установим проверку на нашу машину.
 Как только вы все еще проверите, мы можем перейти к коду.
 Мы создадим следующую структуру каталогов. Создайте эти папки и коснитесь этих файлов.
  Создание файла заголовка 
 Мы создадим простое решение Calculator, чтобы опробовать модульные тесты с помощью Check. Так что, если вы не знакомы с ООП, как программирование на C, вы можете сначала проверить это. Наш калькулятор будет довольно простым, мы будем выполнять основные арифметические функции. Итак, давайте начнем с файла заголовка (calc.h).
 Здесь у нас есть определение типа (typedef) Calc, которое представляет калькулятор. Здесь у нас в основном есть указатели функций на все математические операции (также известные как методы) за пределами структуры «Объект», у нас есть конструктор и деструктор для типа. Сейчас у нас есть файл заголовка, а затем мы можем перейти к реализации.
  Создание реализации 
 Перейдем к коду реализации C. Посмотрим файл calc.c.
 Здесь у нас есть основные математические операции и деструктор, который в значительной степени вызывает освобождение памяти. У нас также есть метод конструктора (newCalc), который отвечает за создание экземпляра Struct в памяти, а также связывает указатель функции с конкретными реализациями.
  Кодирование тестов 
 Теперь мы можем перейти к модульному тесту. Здесь нам нужно будет сделать 2 вещи. Прежде всего, нам нужно будет создать необходимые тесты uni, а затем нам нужно будет настроить тестовый пример и запустить тесты с помощью функции main на C. Поехали.
 Здесь у нас есть тесты для функции: test_new_calc. Здесь также есть несколько макросов начала и конца тестов. Мы создаем новый экземпляр calc и применяем утверждения, как на любом другом языке.
 Наконец, нам нужно настроить набор тестов e и запустить тесты. По сути, мы создаем набор тестов и добавляем в него ваши тесты.Если бы я хотел, я мог бы добавить больше тестов, и мне не понадобилось бы больше бегунов.
  Запуск тестов 
 Перед запуском тестов нам нужен простой скрипт, чтобы правильно связать тесты (нам нужна связь с проверочной структурой), затем нам нужно запустить, а также удалить двоичный файл тестов. Немногие могут отказаться от моего скрипта и использовать Makefile прямо, если хотите.
 Здесь мы используем GCC для построения кода.
No related posts.