Как написать тест на python

Время на прочтение
14 мин

Количество просмотров 77K

Всем доброго!

От нашего стола к вашему…

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

Это руководство для тех, кто уже написал классное приложение на Python, но еще не писал для
них тесты.

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

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

Тестирование Кода

Тестировать код можно разными способами. В этом руководстве вы познакомитесь с методами от наиболее простых до продвинутых.

Автоматизированное vs. Ручное Тестирование

Хорошие новости! Скорее всего вы уже сделали тест, но еще не осознали этого. Помните, как вы впервые запустили приложение и воспользовались им? Вы проверили функции и поэкспериментировали с ними? Такой процесс называется исследовательским тестированием, и он является формой ручного тестирования.

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

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

Звучит безрадостно, верно?

Поэтому нужны автоматические тесты. Автоматическое тестирование — исполнение плана тестирования (части приложения, требующие тестирования, порядок их тестирования и ожидаемые результаты) с помощью скрипта, а не руками человека. В Python уже есть набор инструментов и библиотек, которые помогут создать автоматизированные тесты для вашего приложения. Рассмотрим эти инструменты и библиотеки в нашем туториале.

Модульные Тесты VS. Интеграционные Тесты

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

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

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

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

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

Модульный тест (юнит-тест) — небольшой тест, проверяющий корректность работы отдельного компонента. Модульный тест помогает изолировать поломку и быстрее устранить ее.

Мы поговорили о двух видах тестов:

1. Интеграционный тест, проверяющий компоненты системы и их взаимодействие друг с другом;
2. Модульный тест, проверяющий отдельный компонент приложения.
3. Вы можете создать оба теста на Python. Чтобы написать тест для встроенной функции sum(), нужно сравнить выходные данные sum() с известными значениями.

Например, вот так можно проверить что сумма чисел (1, 2, 3) равна 6:

>>> assert sum([1, 2, 3]) == 6, "Should be 6"

Значения правильные, поэтому в REPL ничего не будет выведено. Если результат sum() некорректный, будет выдана AssertionError с сообщением “Should be 6” (“Должно быть 6”). Проверим оператор утверждения еще раз, но теперь с некорректными значениями, чтобы получить AssertionError:

>>> assert sum([1, 1, 1]) == 6, "Should be 6"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError: Should be 6

В REPL вы увидете AssertionError, так как значение sum() не равно 6.

Вместо REPL, положите это в новый Python-файл с названием test_sum.py и выполните его снова:

def test_sum():
    assert sum([1, 2, 3]) == 6, "Should be 6"

if __name__ == "__main__":
    test_sum()
    print("Everything passed")

Теперь у вас есть написанный тест-кейс (тестовый случай), утверждение и точка входа (командной строки). Теперь это можно выполнить в командной строке:

$ python test_sum.py
Everything passed

Вы видите успешный результат, “Everything passed” (“Все пройдено”).

sum() в Python принимает на вход любой итерируемый в качестве первого аргумента. Вы проверили список. Попробуем протестировать кортеж. Создадим новый файл с названием test_sum_2.py со следующим кодом:

def test_sum():
    assert sum([1, 2, 3]) == 6, "Should be 6"

def test_sum_tuple():
    assert sum((1, 2, 2)) == 6, "Should be 6"

if __name__ == "__main__":
    test_sum()
    test_sum_tuple()
    print("Everything passed")

Выполнив test_sum_2.py, скрипт выдаст ошибку, так как sum() (1, 2, 2) должен быть равен 5, а не 6. В результате скрипт выдает сообщение об ошибке, строку кода и трейсбек:

$ python test_sum_2.py
Traceback (most recent call last):
  File "test_sum_2.py", line 9, in <module>
    test_sum_tuple()
  File "test_sum_2.py", line 5, in test_sum_tuple
    assert sum((1, 2, 2)) == 6, "Should be 6"
AssertionError: Should be 6

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

Такие тесты подойдут для простой проверки, но что если ошибки есть больше, чем в одном? На помощь приходят исполнители тестов (test runners). Исполнитель тестов — особое приложение, спроектированное для проведение тестов, проверки данных вывода и предоставления инструментов для отладки и диагностики тестов и приложений.

Выбор Исполнителя Тестов

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

• unittest;
• nose или nose2;
• pytest.

Важно выбрать исполнитель тестов, соответствующий вашим требованиям и опытности.

unittest

unittest встроен в стандартную библиотеку Python, начиная с версии 2.1. Вы наверняка столкнетесь с ним в коммерческих приложениях Python и проектах с открытым исходным кодом.
В unittest есть тестовый фреймворк и исполнитель тестов. При написании и исполнении тестов нужно соблюдать некоторые важные требования.

unittest требует:

• Помещать тесты в классы, как методы;
• Использовать специальные методы утверждения. Класс TestCase вместо обычного встроенного выражения assert.

Чтобы превратить ранее написанный пример в тест-кейс unittest, необходимо:

1. Импортировать unittest из стандартной библиотеки;
2. Создать класс под названием TestSum, который будет наследовать класс TestCase;
3. Сконвертировать тестовые функции в методы, добавив self в качестве первого аргумента;
4. Изменить утверждения, добавив использование self.assertEqual() метода в классе TestCase;
5. Изменить точку входа в командной строке на вызов unittest.main().

Следуя этим шагам, создайте новый файл test_sum_unittest.py со таким кодом:

import unittest


class TestSum(unittest.TestCase):

    def test_sum(self):
        self.assertEqual(sum([1, 2, 3]), 6, "Should be 6")

    def test_sum_tuple(self):
        self.assertEqual(sum((1, 2, 2)), 6, "Should be 6")

if __name__ == '__main__':
    unittest.main()

Выполнив это в командной строке, вы получите одно удачное завершение (обозначенное .) и одно неудачное (обозначенное F):

$ python test_sum_unittest.py
.F
======================================================================
FAIL: test_sum_tuple (__main__.TestSum)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_sum_unittest.py", line 9, in test_sum_tuple
    self.assertEqual(sum((1, 2, 2)), 6, "Should be 6")
AssertionError: Should be 6

----------------------------------------------------------------------
Ran 2 tests in 0.001s

FAILED (failures=1)

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

Примечание: Если вы пишете тест-кейсы для Python 2 и 3 — будьте осторожны. В версиях Python 2.7 и ниже unittest называется unittest 2. При импорте из unittest вы получите разные версии с разными функциями в Python 2 и Python 3.

Чтобы узнать больше о unittest’ах почитайте unittest документацию.

nose

Со временем, после написания сотни, а то и тысячи тестов для приложения, становится все сложнее понимать и использовать данные вывода unittest.

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

Для начала работы с nose2 нужно установить его из PyPl и запустить в командной строке. nose2 попытается найти все тестовые скрипы с test*.py в названии и все тест-кейсы, унаследованные из unittest.TestCase в вашей текущей директории:

$ pip install nose2
$ python -m nose2
.F
======================================================================
FAIL: test_sum_tuple (__main__.TestSum)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_sum_unittest.py", line 9, in test_sum_tuple
    self.assertEqual(sum((1, 2, 2)), 6, "Should be 6")
AssertionError: Should be 6

----------------------------------------------------------------------
Ran 2 tests in 0.001s

FAILED (failures=1)

Так выполняется тест, созданный в test_sum_unittest.py, из исполнителя тестов nose2. nose2 предоставляет множество флагов командной строки для фильтрации исполняемых тестов. Чтобы узнать больше, советуем ознакомиться с документацией Nose 2.

pytest

pytest поддерживает выполнение тест-кейсов unittest. Но настоящее преимущество pytest — его тест-кейсы. Тест-кейсы pytest — серия функций в Python-файле с test_ в начале названия.

Есть в нем и другие полезные функции:

• Поддержка встроенных выражений assert вместо использования специальных self.assert*() методов;
• Поддержка фильтрации тест-кейсов;
• Возможность повторного запуска с последнего проваленного теста;
• Экосистема из сотен плагинов, расширяющих функциональность.

Пример тест-кейса TestSum для pytest будет выглядеть следующим образом:

def test_sum():
    assert sum([1, 2, 3]) == 6, "Should be 6"

def test_sum_tuple():
    assert sum((1, 2, 2)) == 6, "Should be 6"

Вы избавились от TestCase, использования классов и точек входа командной строки.
Больше информации можно найти на Сайте Документации Pytest.

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

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

Создайте новую папку для проекта, внутри которой создайте новую папку с названием my_sum. Внутри my_sum создайте пустой файл с названием _init_.py. Наличие этого файла значит, что папка my_sum может быть импортирована в виде модуля из родительской директории.

Структура папок будет выглядеть так:

project/
│
└── my_sum/
└── __init__.py

Откройте my_sum/__init__.py и создайте новую функцию с названием sum(), которая берет на вход итерируемые (список, кортеж, множество) и складывает значения.

def sum(arg):
    total = 0
    for val in arg:
        total += val
    return total

В этом примере создается переменная под названием total, перебираются все значения в arg и добавляются к total. Затем, по завершении итерации, результат возвращается.

Где Писать Тест

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

project/
│
├── my_sum/
│ └── __init__.py
|
└── test.py

Вы заметите, что по мере добавления новых тестов, ваш файл становится все более громоздким и сложным для поддержки, поэтому советуем создать папку tests/ и разделить тесты на несколько файлов. Убедитесь, что названия всех файлов начинаются с test_, чтобы исполнители тестов понимали, что файлы Python содержат тесты, которые нужно выполнить. На больших проектах тесты делят на несколько директорий в зависимости от их назначения или использования.

Примечание: А что есть ваше приложение представляет собой один скрипт?
Вы можете импортировать любые атрибуты скрипта: классы, функции или переменные, с помощью встроенной функции __import__(). Вместо from my_sum import sum напишите следующее:

target = __import__("my_sum.py")
sum = target.sum

При использовании __import__() вам не придется превращать папку проекта в пакет, и вы сможете указать имя файла. Это полезно, если имя файла конфликтует с названиями стандартных библиотек пакетов. Например, если math.py конфликтует с math модулем.

Как Структурировать Простой Тест

Перед написанием тестов, нужно решить несколько вопросов:

1. Что вы хотите протестировать?
2. Вы пишете модульный тест или интеграционный тест?

Сейчас вы тестируете sum(). Для него можно проверить разные поведения, например:

• Можно ли суммировать список целых чисел?
• Можно ли суммировать кортеж или множество?
• Можно ли суммировать список чисел с плавающей точкой?
• Что будет, если дать на вход плохое значение: одно целое число или строку?
• Что будет, если одно из значений отрицательное?

Проще всего тестировать список целых чисел. Создайте файл test.py со следующим кодом:

import unittest

from my_sum import sum


class TestSum(unittest.TestCase):
    def test_list_int(self):
        """
        Test that it can sum a list of integers
        """
        data = [1, 2, 3]
        result = sum(data)
        self.assertEqual(result, 6)

if __name__ == '__main__':
    unittest.main()

Код в этом примере:

• Импортирует sum() из пакета my_sum(), который вы создали;
• Определяет новый класс тест-кейса под названием TestSum, наследующий unittest.TestCase;
• Определяет тестовый метод .test_list_int() для тестирования целочисленного списка. Метод .test_list_int() сделает следующее

:

1. Объявит переменную data со списком значений (1, 2, 3);
2. Присвоит значение my_sum.sum(data) переменной result;
3. Определит, что значение result равно 6 с помощью метода .assertEqual() на unittest.TestCase классе.

• Определяет точку входа командной строки, которая запускает исполнителя теста unittest .main().

Если вы не знаете, что такое self, или как определяется .assertEqual(), то можете освежить знания по объектно-ориентированному программированию с Python 3 Object-Oriented Programming.

Как Писать Утверждения

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

• Проверьте, что тесты повторяемы и запустите их несколько раз, чтобы убедиться, что каждый раз они дают одни и те же результаты;
• Проверьте и подтвердите результаты, которые относятся к вашим входным данным — проверьте, что результат действительно является суммой значений в примере sum().

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

У .assertIs(), .assertIsNone(), .assertIn(), and .assertIsInstance() есть противоположные методы, называемые .assertIsNot() и тд.

Побочные эффекты

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

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

Запуск Первого Теста

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

Запуск Исполнителей Тестов

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

if __name__ == '__main__':
    unittest.main()

Это точка входа командной строки. Если вы выполните этот скрипт, запустив python test.py в командной строке, он вызовет unittest.main(). Это запускает исполнителя тестов, обнаруживая все классы в этом файле, наследуемые из unittest.TestCase.

Это один из многих способов запуска исполнителя тестов unittest. Если у вас есть единственный тестовый файл с названием test.py, вызов python test.py — отличный способ начать работу.

Другой способ — использовать командную строку unittest. Попробуем:

$ python -m unittest test

Это исполнит тот же самый тестовый модуль (под названием test) через командную строку. Можно добавить дополнительные параметры для изменения выходных данных. Один из них -v для многословности (verbose). Попробуем следующее:

$ python -m unittest -v test
test_list_int (test.TestSum) ... ok

----------------------------------------------------------------------
Ran 1 tests in 0.000s

Мы исполнили один тест из test.py и вывели результаты в консоль. Многословный режим перечислил имена выполненных тестов и результаты каждого из них.

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

$ python -m unittest discover

Эта команда будет искать в текущей директории файлы с test*.py в названии, чтобы протестировать их.

При наличии нескольких тестовых файлов и соблюдении шаблона наименования test*.py, можно передать имя директории при помощи -s флага и названия папки.

$ python -m unittest discover -s tests

unittest запустит все тесты в едином тестовом плане и выдаст результаты.
Наконец, если ваш исходный код находится не в корневом каталоге, а в подкаталоге, например в папке с названием src/, можно с помощью -t флага сообщить unittest, где выполнять тесты, для корректного импорта модулей:

$ python -m unittest discover -s tests -t src

unittest найдет все файлы test*.py в директории src/ внутри tests, а затем выполнит их.

Понимание Результатов Тестирование

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

sum() должен принимать на вход другие списки числового типа, например дроби.

К началу кода в файле test.py добавьте выражение для импорта типа Fraction из модуля fractions стандартной библиотеки.

from fractions import Fraction

Теперь добавим тест с утверждением, ожидая некорректное значение. В нашем случае, ожидаем, что сумма ¼, ¼ и ⅖ будет равна 1:

import unittest

from my_sum import sum


class TestSum(unittest.TestCase):
    def test_list_int(self):
        """
        Test that it can sum a list of integers
        """
        data = [1, 2, 3]
        result = sum(data)
        self.assertEqual(result, 6)

    def test_list_fraction(self):
        """
        Test that it can sum a list of fractions
        """
        data = [Fraction(1, 4), Fraction(1, 4), Fraction(2, 5)]
        result = sum(data)
        self.assertEqual(result, 1)

if __name__ == '__main__':
    unittest.main()
 

Если вы запустите тесты повторно с python -m unittest test, получите следующее:

$ python -m unittest test
F.
======================================================================
FAIL: test_list_fraction (test.TestSum)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 21, in test_list_fraction
    self.assertEqual(result, 1)
AssertionError: Fraction(9, 10) != 1

----------------------------------------------------------------------
Ran 2 tests in 0.001s

FAILED (failures=1)

В этих выходных данных вы видите следующее:

• В первой строке указаны результаты выполнения всех тестов: один проваленный (F), один пройденный (.);
• FAIL показывает некоторые детали проваленного теста:

1. Название тестового метода (test_list_fraction);
2. Тестовый модуль (test) и тест-кейс (TestSum);
3. Трейсбек строки с ошибкой;
4. Детали утверждения с ожидаемым результатом (1) и фактическим результатом (Fraction(9, 10))

Помните, можно добавить дополнительную информацию к выходным данным теста с помощью флага -v к команде python -m unittest.

Запуск тестов из PyCharm

Если вы используете PyCharm IDE, то можете запустить unittest или pytest, выполнив следующие шаги:

1. В окне Project tool, выберите директорию tests.
2. В контекстном меню выберите команду запуска unittest. Например, ‘Unittests in my Tests…’.

Это выполнит unittest в тестовом окне и выдаст результаты в PyCharm:

Больше информации доступно на сайте PyCharm.

Запуск Тестов из Visual Studio Code

Если вы пользуетесь Microsoft Visual Studio Code IDE, поддержка unittest, nose и pytest уже встроена в плагин Python.

Если он у вас установлен, можно настроить конфигурацию тестов, открыв Command Palette по Ctrl+Shift+P и написав “Python test”. Вы увидите список вариантов:

Выберите Debug All Unit Tests, после чего VSCode отправит запрос для настройки тестового фреймворка. Кликните по шестеренке для выбора исполнителя тестов (unittest) и домашней директории (.).

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

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

THE END

В следующей части статьи мы рассмотрим тесты для фреймворков, таких как Django и Flask.

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

Вторая часть

Watch Now This tutorial has a related video course created by the Real Python team. Watch it together with the written tutorial to deepen your understanding: Test-Driven Development With PyTest

This tutorial is for anyone who has written a fantastic application in Python but hasn’t yet written any tests.

Testing in Python is a huge topic and can come with a lot of complexity, but it doesn’t need to be hard. You can get started creating simple tests for your application in a few easy steps and then build on it from there.

In this tutorial, you’ll learn how to create a basic test, execute it, and find the bugs before your users do! You’ll learn about the tools available to write and execute tests, check your application’s performance, and even look for security issues.

>>> assert sum([1, 2, 3]) == 6, "Should be 6"

>>> assert sum([1, 1, 1]) == 6, "Should be 6"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError: Should be 6

def test_sum():
    assert sum([1, 2, 3]) == 6, "Should be 6"

if __name__ == "__main__":
    test_sum()
    print("Everything passed")

$ python test_sum.py
Everything passed

def test_sum():
    assert sum([1, 2, 3]) == 6, "Should be 6"

def test_sum_tuple():
    assert sum((1, 2, 2)) == 6, "Should be 6"

if __name__ == "__main__":
    test_sum()
    test_sum_tuple()
    print("Everything passed")

$ python test_sum_2.py
Traceback (most recent call last):
  File "test_sum_2.py", line 9, in <module>
    test_sum_tuple()
  File "test_sum_2.py", line 5, in test_sum_tuple
    assert sum((1, 2, 2)) == 6, "Should be 6"
AssertionError: Should be 6

import unittest


class TestSum(unittest.TestCase):

    def test_sum(self):
        self.assertEqual(sum([1, 2, 3]), 6, "Should be 6")

    def test_sum_tuple(self):
        self.assertEqual(sum((1, 2, 2)), 6, "Should be 6")

if __name__ == '__main__':
    unittest.main()

$ python test_sum_unittest.py
.F
======================================================================
FAIL: test_sum_tuple (__main__.TestSum)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_sum_unittest.py", line 9, in test_sum_tuple
    self.assertEqual(sum((1, 2, 2)), 6, "Should be 6")
AssertionError: Should be 6

----------------------------------------------------------------------
Ran 2 tests in 0.001s

FAILED (failures=1)

$ pip install nose2
$ python -m nose2
.F
======================================================================
FAIL: test_sum_tuple (__main__.TestSum)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_sum_unittest.py", line 9, in test_sum_tuple
    self.assertEqual(sum((1, 2, 2)), 6, "Should be 6")
AssertionError: Should be 6

----------------------------------------------------------------------
Ran 2 tests in 0.001s

FAILED (failures=1)

def test_sum():
    assert sum([1, 2, 3]) == 6, "Should be 6"

def test_sum_tuple():
    assert sum((1, 2, 2)) == 6, "Should be 6"

project/
│
└── my_sum/
    └── __init__.py

def sum(arg):
    total = 0
    for val in arg:
        total += val
    return total

project/
│
├── my_sum/
│   └── __init__.py
|
└── test.py

import unittest

from my_sum import sum


class TestSum(unittest.TestCase):
    def test_list_int(self):
        """
        Test that it can sum a list of integers
        """
        data = [1, 2, 3]
        result = sum(data)
        self.assertEqual(result, 6)

if __name__ == '__main__':
    unittest.main()

if __name__ == '__main__':
    unittest.main()

$ python -m unittest test

$ python -m unittest -v test
test_list_int (test.TestSum) ... ok

----------------------------------------------------------------------
Ran 1 tests in 0.000s

$ python -m unittest discover

$ python -m unittest discover -s tests

$ python -m unittest discover -s tests -t src

from fractions import Fraction

import unittest

from my_sum import sum


class TestSum(unittest.TestCase):
    def test_list_int(self):
        """
        Test that it can sum a list of integers
        """
        data = [1, 2, 3]
        result = sum(data)
        self.assertEqual(result, 6)

    def test_list_fraction(self):
        """
        Test that it can sum a list of fractions
        """
        data = [Fraction(1, 4), Fraction(1, 4), Fraction(2, 5)]
        result = sum(data)
        self.assertEqual(result, 1)

if __name__ == '__main__':
    unittest.main()

$ python -m unittest test
F.
======================================================================
FAIL: test_list_fraction (test.TestSum)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 21, in test_list_fraction
    self.assertEqual(result, 1)
AssertionError: Fraction(9, 10) != 1

----------------------------------------------------------------------
Ran 2 tests in 0.001s

FAILED (failures=1)

from django.test import TestCase

class MyTestCase(TestCase):
    # Your test methods

import my_app
import unittest


class MyTestCase(unittest.TestCase):

    def setUp(self):
        my_app.app.testing = True
        self.app = my_app.app.test_client()

    def test_home(self):
        result = self.app.get('/')
        # Make your assertions

import unittest

from my_sum import sum


class TestSum(unittest.TestCase):
    def test_list_int(self):
        """
        Test that it can sum a list of integers
        """
        data = [1, 2, 3]
        result = sum(data)
        self.assertEqual(result, 6)

    def test_list_fraction(self):
        """
        Test that it can sum a list of fractions
        """
        data = [Fraction(1, 4), Fraction(1, 4), Fraction(2, 5)]
        result = sum(data)
        self.assertEqual(result, 1)

    def test_bad_type(self):
        data = "banana"
        with self.assertRaises(TypeError):
            result = sum(data)

if __name__ == '__main__':
    unittest.main()

project/
│
├── my_app/
│   └── __init__.py
│
└── tests/
    |
    ├── unit/
    |   ├── __init__.py
    |   └── test_sum.py
    |
    └── integration/
        ├── __init__.py
        └── test_integration.py

$ python -m unittest discover -s tests/integration

project/
│
├── my_app/
│   └── __init__.py
│
└── tests/
    |
    └── unit/
    |   ├── __init__.py
    |   └── test_sum.py
    |
    └── integration/
        |
        ├── fixtures/
        |   ├── test_basic.json
        |   └── test_complex.json
        |
        ├── __init__.py
        └── test_integration.py

import unittest


class TestBasic(unittest.TestCase):
    def setUp(self):
        # Load test data
        self.app = App(database='fixtures/test_basic.json')

    def test_customer_count(self):
        self.assertEqual(len(self.app.customers), 100)

    def test_existence_of_customer(self):
        customer = self.app.get_customer(id=10)
        self.assertEqual(customer.name, "Org XYZ")
        self.assertEqual(customer.address, "10 Red Road, Reading")


class TestComplexData(unittest.TestCase):
    def setUp(self):
        # load test data
        self.app = App(database='fixtures/test_complex.json')

    def test_customer_count(self):
        self.assertEqual(len(self.app.customers), 10000)

    def test_existence_of_customer(self):
        customer = self.app.get_customer(id=9999)
        self.assertEqual(customer.name, u"バナナ")
        self.assertEqual(customer.address, "10 Red Road, Akihabara, Tokyo")

if __name__ == '__main__':
    unittest.main()

[tox]
envlist = py27, py36

[testenv]
deps =

commands =
    python -m unittest discover

[tox]
envlist = py27, py36
skipsdist=True

language: python
python:
  - "2.7"
  - "3.7"
install:
  - pip install -r requirements.txt
script:
  - python -m unittest discover

$ flake8 test.py
test.py:6:1: E302 expected 2 blank lines, found 1
test.py:23:1: E305 expected 2 blank lines after class or function definition, found 1
test.py:24:20: W292 no newline at end of file

[flake8]
ignore = E305
exclude = .git,__pycache__
max-line-length = 90

$ flake8 --ignore E305 --exclude .git,__pycache__ --max-line-length=90

matrix:
  include:
    - python: "2.7"
      script: "flake8"

$ flake8 --max-line-length=120 tests/

def test():
    # ... your code

if __name__ == '__main__':
    import timeit
    print(timeit.timeit("test()", setup="from __main__ import test", number=100))

$ pip install pytest-benchmark

def test_my_function(benchmark):
    result = benchmark(test)

$ bandit -r my_sum
[main]  INFO    profile include tests: None
[main]  INFO    profile exclude tests: None
[main]  INFO    cli include tests: None
[main]  INFO    cli exclude tests: None
[main]  INFO    running on Python 3.5.2
Run started:2018-10-08 00:35:02.669550

Test results:
        No issues identified.

Code scanned:
        Total lines of code: 5
        Total lines skipped (#nosec): 0

Run metrics:
        Total issues (by severity):
                Undefined: 0.0
                Low: 0.0
                Medium: 0.0
                High: 0.0
        Total issues (by confidence):
                Undefined: 0.0
                Low: 0.0
                Medium: 0.0
                High: 0.0
Files skipped (0):

[bandit]
exclude: /test
tests: B101,B102,B301

Watch Now This tutorial has a related video course created by the Real Python team. Watch it together with the written tutorial to deepen your understanding: Test-Driven Development With PyTest

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

Действующий пример

Прежде чем погрузиться в принципы, эвристики и руководства, давайте посмотрим репрезентативный модульный тест в действии. Класс SelfDrivingCar это частичное выполнение логики вождения автопилота автомобиля. Главным образом он контролирует скорость автомобиля. Он рспознаёт объекты впереди, ограничение скорости, а также прибытие или нет в пункт назначения.

1

class SelfDrivingCar(object):

2

3

    def __init__(self):

4

5

        self.speed = 0

6

7

        self.destination = None

8

9

10

11

    def _accelerate(self):

12

13

        self.speed += 1

14

15

16

17

    def _decelerate(self):

18

19

        if self.speed > 0:

20

21

            self.speed -= 1

22

23

24

25

    def _advance_to_destination(self):

26

27

        distance = self._calculate_distance_to_object_in_front()

28

29

        if distance < 10:

30

31

            self.stop()

32

33

34

35

        elif distance < self.speed / 2:

36

37

            self._decelerate()

38

39

        elif self.speed < self._get_speed_limit():

40

41

            self._accelerate()

42

43

44

45

    def _has_arrived(self):

46

47

        pass

48

49

50

51

    def _calculate_distance_to_object_in_front(self):

52

53

        pass

54

55

56

57

    def _get_speed_limit(self):

58

59

        pass

60

61

62

63

    def stop(self):

64

65

        self.speed = 0

66

67

68

69

    def drive(self, destination):

70

71

        self.destination = destination

72

73

        while not self._has_arrived():            

74

75

            self._advance_to_destination()

76

77

78

        self.stop()

79

80

    def __init__(self):

81

82

        self.speed = 0

83

84

        self.destination = None

85

86

87

88

    def _accelerate(self):

89

90

        self.speed += 1

91

92

93

94

    def _decelerate(self):

95

96

        if self.speed > 0:

97

98

            self.speed -= 1

99

100

101

102

    def _advance_to_destination(self):

103

104

        distance = self._calculate_distance_to_object_in_front()

105

106

        if distance < 10:

107

108

            self.stop()

109

110

111

112

        elif distance < self.speed / 2:

113

114

            self._decelerate()

115

116

        elif self.speed < self._get_speed_limit():

117

118

            self._accelerate()

119

120

121

122

    def _has_arrived(self):

123

124

        pass

125

126

127

128

    def _calculate_distance_to_object_in_front(self):

129

130

        pass

131

132

133

134

    def _get_speed_limit(self):

135

136

        pass

137

138

139

140

    def stop(self):

141

142

        self.speed = 0

143

144

145

146

    def drive(self, destination):

147

148

        self.destination = destination

149

150

        while not self._has_arrived():            

151

152

            self._advance_to_destination()

153

154

        self.stop()

155

Вот модульный тест для метода stop() чтобы раззадорить ваш аппетит. Я расскажу подробности позже.

1

from unittest import TestCase

2

3

4

5

class SelfDrivingCarTest(TestCase):

6

7

    def setUp(self):

8

9

        self.car = SelfDrivingCar()

10

11

12

13

    def test_stop(self):

14

15

        self.car.speed = 5

16

17

        self.car.stop()

18

19

        # Verify the speed is 0 after stopping

20

21

        self.assertEqual(0, self.car.speed)

22

23

24

25

        # Verify it is Ok to stop again if the car is already stopped

26

27

        self.car.stop()

28

29

        self.assertEqual(0, self.car.speed)

Руководство по модульному тестированию

Основные идеи

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

Будьте дисциплинированы

Вы должны быть дисциплинированным. Будьте последовательным. Убедитесь, что все тесты выполнены. Не отказывайтесь от тестов, только потому что вы «знаете», что код в порядке.

Автоматизируйте

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

Непротестированный код плохой по определению

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

Пояснения

Что такое модуль?

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

Делать TDD или не делать TDD

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

Причина заключается в том, что я проектирую код. Я пишу код, смотрю на него, переписываю, еще раз смотрю и быстро переписываю ещё раз. Написание тестов сначала ограничивает и замедляет меня.

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

Unittest модуль

Модуль Unittest поставляется со стандартной библиотекой Python. Она предоставляет собой класс под названием TestCase, из которого можно вызвать ваш класс. Затем можно переопределить метод setUp() чтобы подготовить среду до начала тестирования и/или метод класса classSetUp() чтобы подготовить среду для всех тестов (не очищающуюся между разными тестами). Существуют соответствующие методы tearDown() и classTearDown(), которые также можно переопределить.

Ниже приведены соответствующие разделы из нашего класса SelfDrivingCarTest. Я использую только метод setUp(). Я создаю новый экземпляр SelfDrivingCar и сохраняю его в self.car, поэтому он доступен для каждого теста.

1

from unittest import TestCase

2

3

4

5

class SelfDrivingCarTest(TestCase):

6

7

    def setUp(self):

8

9

        self.car = SelfDrivingCar()

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

• Подготовка среды (необязательно).
• Подготовьте ожидаемый результат.
• Вызовите код теста.
• Убедитесь, что фактический результат совпадает с ожидаемым результатом.

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

Например метод stop() класса SelfDrivingCar не возвращает ничего, но он меняет внутреннее состояние, устанавливая скорость на 0. Метод assertEqual(), предоставляемый базовым классом TestCase используется здесь для проверки, того что вызов stop() работает, как и требуется.

1

def test_stop(self):

2

3

        self.car.speed = 5

4

5

        self.car.stop()

6

7

        # Verify the speed is 0 after stopping

8

9

        self.assertEqual(0, self.car.speed)

10

11

12

13

        # Verify it is Ok to stop again if the car is already stopped

14

15

        self.car.stop()

16

17

        self.assertEqual(0, self.car.speed)

Здесь на самом деле два теста. Первый тест, чтобы убедиться, что если скорость автомобиля равна 5 и stop() вызывается, то скорость становится равна 0. И еще один тест, чтобы убедиться, что ничего не случится, если вызвать stop() снова, когда автомобиль уже остановился.

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

Doctest модуль

Doctest модуль очень интерестный. Он позволяет использовать интерактивные примеры в docstring и проверять результаты, включая исключения.

Я не применяют и не рекомендую использовать doctest для крупномасштабных систем. Хорошее тестирование требует много труда. Тест-код обычно намного больше, чем тестируемый код. Docstrings — это не совсем подходящий инструмент для написания комплексных тестов. Хотя они классные Вот как выглядит factorial функция для doc-тестов:

1

import math

2

3

4

5

def factorial(n):

6

7

    """Return the factorial of n, an exact integer >= 0.

8

9

10

11

    If the result is small enough to fit in an int, return an int.

12

13

    Else return a long.

14

15

16

17

    >>> [factorial(n) for n in range(6)]

18

19

    [1, 1, 2, 6, 24, 120]

20

21

    >>> [factorial(long(n)) for n in range(6)]

22

23

    [1, 1, 2, 6, 24, 120]

24

25

    >>> factorial(30)

26

27

    265252859812191058636308480000000L

28

29

    >>> factorial(30L)

30

31

    265252859812191058636308480000000L

32

33

    >>> factorial(-1)

34

35

    Traceback (most recent call last):

36

37

        ...

38

39

    ValueError: n must be >= 0

40

41

42

43

    Factorials of floats are OK, but the float must be an exact integer:

44

45

    >>> factorial(30.1)

46

47

    Traceback (most recent call last):

48

49

        ...

50

51

    ValueError: n must be exact integer

52

53

    >>> factorial(30.0)

54

55

    265252859812191058636308480000000L

56

57

58

59

    It must also not be ridiculously large:

60

61

    >>> factorial(1e100)

62

63

    Traceback (most recent call last):

64

65

        ...

66

67

    OverflowError: n too large

68

69

    """

70

71

    if not n >= 0:

72

73

        raise ValueError("n must be >= 0")

74

75

    if math.floor(n) != n:

76

77

        raise ValueError("n must be exact integer")

78

79

    if n+1 == n:  # catch a value like 1e300

80

81

        raise OverflowError("n too large")

82

83

    result = 1

84

85

    factor = 2

86

87

    while factor <= n:

88

89

        result *= factor

90

91

        factor += 1

92

93

    return result

94

95

96

97

98

99

if __name__ == "__main__":

100

101

    import doctest

102

103

    doctest.testmod()

Как вы видите, docstring намного больше, чем код функции. Это не улучшает читаемость кода.

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

OK. Вы написали модульные тесты. Для большой системы у вас будет десятки / сотни / тысячи модулей и классов, возможно,размещенных в разных папках. Как вы будете запускаете все тесты?

Модуль unittest дает различные возможности для проведения групповых тестов и их программирования. Проверка Загрузки и Выполнения тестов /Loading and Running Tests. Но самый простой способ — открытие теста. Данный параметр был добавлен только в Python 2.7. В Pre-2.7 вы могли использовать nose, чтобы найти и запустить тесты. У nose есть несколько других преимуществ, таких как запуск тестовых функций без необходимости создания класса для ваших тестовых случаев. Но для целей в этой статьи, давайте придерживаться unittest.

Чтобы найти и запустить тесты на основе unittest, просто введите в командной строке:

python -m unittest discover

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

python -m unittest discover -v

Существует несколько флагов, которые управляют операцией:

1

python -m unittest -h

2

3

Usage: python -m unittest [options] [tests]

4

5

6

7

Options:

8

9

  -h, --help       Show this message

10

11

  -v, --verbose    Verbose output

12

13

  -q, --quiet      Minimal output

14

15

  -f, --failfast   Stop on first failure

16

17

  -c, --catch      Catch control-C and display results

18

19

  -b, --buffer     Buffer stdout and stderr during test runs

20

21

22

23

Examples:

24

25

  python -m unittest test_module               - run tests from test_module

26

27

  python -m unittest module.TestClass          - run tests from module.TestClass

28

29

  python -m unittest module.Class.test_method  - run specified test method

30

31

32

33

[tests] can be a list of any number of test modules, classes and test

34

35

methods.

36

37

38

39

Alternative Usage: python -m unittest discover [options]

40

41

42

43

Options:

44

45

  -v, --verbose    Verbose output

46

47

  -f, --failfast   Stop on first failure

48

49

  -c, --catch      Catch control-C and display results

50

51

  -b, --buffer     Buffer stdout and stderr during test runs

52

53

  -s directory     Directory to start discovery ('.' default)

54

55

  -p pattern       Pattern to match test files ('test*.py' default)

56

57

  -t directory     Top level directory of project (default to

58

59

                   start directory)

60

61

62

63

For test discovery all test modules must be importable from the top

64

65

level directory of the project.

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

Определение степени покрытия кода часто игнорируют. Само понятие означает, сколько кода действительно проверено тестами. Например, если у вас есть функция с инструкцией if-else, и вы проверяете только ветвьif, то вы не знаете, работает ли ветка else или нет.  В следующем примере кода функция add() проверяет тип своих аргументов. Если оба являются целыми числами, они просто добавляют их. 

Если оба являются строками, то он пытается преобразовать их в целые числа и добавить. В противном случае он вызывает исключение. Функция test_add() проверяет функцию add() с аргументами, которые являются как целыми числами, так и аргументами, которые являются плавающим значением и проверяют правильное поведение в каждом случае. Но степень покрытия теста является незавершенной. В случае, если строковые аргументы были не протестированы. В результате тест проходит успешно, но ошибка в ветке, где аргументы были строками, не были обнаружены (см. «intg»?).

1

import unittest

2

3

4

5

def add(a, b):

6

7

    """This function adds two numbers a, b and returns their sum

8

9

10

11

    a and b may integers

12

13

    """

14

15

    if isinstance(a, int) and isinstance(b, int):

16

17

        return a + b

18

19

    elseif isinstance(a, str) and isinstance(b, str):

20

21

        return int(a) + intg(b)

22

23

    else:

24

25

        raise Exception('Invalid arguments')

26

27

28

29

class Test(unittest.TestCase):

30

31

    def test_add(self):

32

33

        self.assertEqual(5, add(2, 3))

34

35

        self.assertEqual(15, add(-6, 21))

36

37

        self.assertRaises(Exception, add, 4.0, 5.0)

38

39

40

41

unittest.main()       

Вот вывод:

1

----------------------------------------------------------------------

2

3

Ran 1 test in 0.000s

4

5

6

7

OK

8

9

10

11

Process finished with exit code 0

Практические Unit Tests

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

Разработка тестирования

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

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

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

Давайте посмотрим, как это работает на практике.  SelfDrivingCar примет аргумент, называемый object_detector, который имеет метод calculate_distance_to_object_in_front(), и он делегирует эту функцию объекту. Теперь нет необходимости в проверке, потому что object_detector отвечает (и должен быть протестирован) за него. Вам по-прежнему нужно, чтобы модуль тестировал то, что вы правильно используете object_detector.

1

class SelfDrivingCar(object):

2

3

    def __init__(self, object_detector):

4

5

        self.object_detector

6

7

        self.speed = 0

8

9

        self.destination = None

10

11

12

13

    def _calculate_distance_to_object_in_front(self):

14

15

        return self.object_detector.calculate_distance_to_object_in_front()

Затраты и выгоды

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

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

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

Мышление тестирования

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

Например, предположим, что ваш код должен что-то вычислять. Для этого ему необходимо загрузить данные из базы, прочитать файл конфигурации и динамически обратиться к некоторыми REST API для получения актуальной информации. Все это может потребоваться по разным причинам, но при этом, ели вы разместите всё это в одной функции, это очень затруднит тестирование. Это возможно звучит смешно, но гораздо лучше изначально структурировать ваш код.

Чистые функции

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

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

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

Почему? Потому что код не изменился. Он все еще ожидает файл конфигурации XML, и ваш тест по-прежнему создает XML-файл для него.  Но при выполнении ваш код получит файл JSON, который он не сможет проанализировать.

Обработка ошибок тестирования

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

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

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

Вот обновленный класс SelfDrivingCar. Я просто выполнил некоторые из нереализованных методов, потому что метод drive() вызывает некоторые из этих методов прямо или косвенно.

1

class SelfDrivingCar(object):

2

3

    def __init__(self, object_detector):

4

5

        self.object_detector = object_detector

6

7

        self.speed = 0

8

9

        self.destination = None

10

11

12

13

    def _accelerate(self):

14

15

        self.speed += 1

16

17

18

19

    def _decelerate(self):

20

21

        if self.speed > 0:

22

23

            self.speed -= 1

24

25

26

27

    def _advance_to_destination(self):

28

29

        distance = self._calculate_distance_to_object_in_front()

30

31

        if distance < 10:

32

33

            self.stop()

34

35

36

37

        elif distance < self.speed / 2:

38

39

            self._decelerate()

40

41

        elif self.speed < self._get_speed_limit():

42

43

            self._accelerate()

44

45

46

47

    def _has_arrived(self):

48

49

        return True

50

51

52

53

    def _calculate_distance_to_object_in_front(self):

54

55

        return self.object_detector.calculate_distance_to_object_in_front()

56

57

58

59

    def _get_speed_limit(self):

60

61

        return 65

62

63

64

65

    def stop(self):

66

67

        self.speed = 0

68

69

70

71

    def drive(self, destination):

72

73

        self.destination = destination

74

75

        while not self._has_arrived():

76

77

            self._advance_to_destination()

78

79

        self.stop()

Чтобы проверить, как обработались ошибки в тесте, я передаю неверные аргументы и думаю, что они должным образом будут отвергнуты. Вы можете сделать это, используя self.assertRaises() метод unittest.TestCase. Этот метод очень удачный, если код под тестированием действительно вызывает исключение.

Давайте посмотрим на это в действии. Метод test_drive() пропускает широту и долготу вне допустимого диапазона и ждет, что метод drive() вызовет исключение.

1

from unittest import TestCase

2

3

from self_driving_car import SelfDrivingCar

4

5

6

7

8

9

class MockObjectDetector(object):

10

11

    def calculate_distance_to_object_in_front(self):

12

13

        return 20

14

15

16

17

18

19

class SelfDrivingCarTest(TestCase):

20

21

    def setUp(self):

22

23

        self.car = SelfDrivingCar(MockObjectDetector())

24

25

26

27

    def test_stop(self):

28

29

        self.car.speed = 5

30

31

        self.car.stop()

32

33

        # Verify the speed is 0 after stopping

34

35

        self.assertEqual(0, self.car.speed)

36

37

38

39

        # Verify it is Ok to stop again if the car is already stopped

40

41

        self.car.stop()

42

43

        self.assertEqual(0, self.car.speed)

44

45

46

47

    def test_drive(self):

48

49

        # Valid destination

50

51

        self.car.drive((55.0, 66.0))

52

53

54

55

        # Invalid destination wrong range

56

57

        self.assertRaises(Exception, self.car.drive, (-55.0, 200.0))

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

1

python -m unittest discover -v

2

3

test_drive (untitled.test_self_driving_car.SelfDrivingCarTest) ... FAIL

4

5

test_stop (untitled.test_self_driving_car.SelfDrivingCarTest) ... ok

6

7

8

9

======================================================================

10

11

FAIL: test_drive (untitled.test_self_driving_car.SelfDrivingCarTest)

12

13

----------------------------------------------------------------------

14

15

Traceback (most recent call last):

16

17

  File "/Users/gigi/PycharmProjects/untitled/test_self_driving_car.py", line 29, in test_drive

18

19

    self.assertRaises(Exception, self.car.drive, (-55.0, 200.0))

20

21

AssertionError: Exception not raised

22

23

24

25

----------------------------------------------------------------------

26

27

Ran 2 tests in 0.000s

28

29

30

31

FAILED (failures=1)

Чтобы исправить это, давайте обновим метод drive(), чтобы фактически проверить диапазон его аргументов:

1

def drive(self, destination):

2

3

        lat, lon = destination

4

5

        if not (0.0 <= lat <= 90.0):

6

7

            raise Exception('Latitude out of range')

8

9

        if not (-180.0 <= lon <= 180.0):

10

11

            raise Exception('Latitude out of range')

12

13

14

15

        self.destination = destination

16

17

        while not self._has_arrived():

18

19

            self._advance_to_destination()

20

21

        self.stop()

Теперь все тесты проходят.

1

python -m unittest discover -v

2

3

test_drive (untitled.test_self_driving_car.SelfDrivingCarTest) ... ok

4

5

test_stop (untitled.test_self_driving_car.SelfDrivingCarTest) ... ok

6

7

8

9

----------------------------------------------------------------------

10

11

Ran 2 tests in 0.000s

12

13

14

15

OK

16

Тестирование частных методов

Должны ли вы проверять каждую функцию и метод? В частности, следует ли тестировать частные методы, называемые только вашим кодом?  Обычный неудовлетворительный ответ: «В зависимости от ситуации».

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

Как организовать ваши модульные тесты

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

Вот система, которую я использую. Тесты должны быть полностью отделены от тестируемого кода (следовательно, я не использую doctest). В идеале ваш код должен быть в пакете. Тесты для каждого пакета должны находиться в каталоге вашего дочернего узла. В каталоге тестов должен быть один файл для каждого модуля вашего пакета с именем test_<module name>.

Например, если в вашем пакете есть три модуля: module_1.py, module_2.py и module_3.py, вы должны иметь три тестовых файла: test_module_1.py, test_module_2.py и test_module_3.py в каталоге тестов.

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

Заключение

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

Here we’ll learn how to create a basic test, execute it, and find the bugs before your users do! You’ll learn about the tools available to write and execute tests and also see testing terms like automated, manual, unit and integration tests as well.

Automated vs. Manual Testing 

Unit Tests vs. Integration Tests 

Example for Unit testing:

Output:

Traceback (most recent call last):
 File "....../test_example.py", line 9, in <module>
   test_sum_tuple_values()
 File "...../test_example.py", line 5, in test_sum_tuple_values
   assert sum((100, 200, 200,400)) == 1000, "Result should be 1000"
AssertionError: Result should be 1000

In the above example, We have two methods here and when code is executed, second method throws error as the given values do not produce 1000. 

Choosing a Test Runner: 

Test Runner is a library or a testing tool which reads the source code that contains unit tests and a bunch of settings which can be executed and produces its output to the console or log files. 
There are different Test Runners available in Python. Popular one are 

• unittest
• nose or nose2
• pytest

unittest : It is built into the standard python library.  import unittest should be the starting line of code for using it. Depends upon the python version, it should differ as later versions of Python supports unittest and earlier versions supported unittest2. 
Sample snippet of python code using unittest is given below:

Output:

======================================================================
.F
FAIL: test_xxxxxxx (__main__.TestXXXXX)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "......py", line 8, in test_xxxxxxx
   self.assertEqual(result, 6000)
AssertionError: 600 != 6000
----------------------------------------------------------------------
Ran 1 test in 0.001s
FAILED (failures=1)

nose or nose2: This is an open source application and similar to unittest only.It is compatible with numerous kinds of tests that are written using unittest framework. nose2 is the recent version one, and they are installed by using. 

pip install nose2 

pytest: It supports unittest test cases execution. It has benefits like supporting built in assert statement, filtering of test cases, returning from last failing test etc

No need to write the class, command line entry point etc.,

How to Structure a Simple Test:

1. For writing a test, need to know what is going to get tested.
2. Does it cover unit testing and/or integration testing?
3. All kind of necessary inputs (it can range between integer, float, type data types etc., ) and the code for their execution and get the output and compare the output with expected result.

How to Write Assertions:

Assertion is nothing but validating the output against a known response. i.e. in above code, we have passed the list containing 3 values namely 10, 20 and 30, and we know that its multiplication result is 6000. So as a last step in code, we will be writing assertion code and above code comes up with assertEqual and surely it will give the output as 6000 and hence the testcase passes. 

unittest has lots of methods to assert on the values, types, and existence of variables. 
Let us see few : 

.assertEqual(one,two) means one == two (Our above example) 
.assertTrue(expr) means boolean(expr) is True 
.assertFalse(expr) means boolean(expr) is False 
.assertIs(one,two) means one is two 

We have opposite methods too like:

 .assertIsNot(one,two) means one is not two. 
.assertIsNone(x) vs .assertIsNone(x) 
.assertIn(x, y) vs .assertNotIn(x, y) 
.assertIsInstance(m, n) vs .assertNotIsInstance(m,n) 

Side Effects:

Continuous execution of piece of code has the possibility to alter other things to change like attribute of a class or even a value in the database. So these are need to be decided before doing testing. Refactoring of code needs to be considered to break the side effects and write repeatable and simple unit tests. 

Running Tests From PyCharm:

We can run unittest or pytest by following the steps and this is applicable for running all tests in a directory:

1. First from project tool window, select the tests directory
2. Then, on the context menu, choose “UnitTests in” or “PyTests in “ 
   For individual test,
   • Via main toolbar by using Run or Debug command
   • Via context menu by using Run or Debug by clicking the specific file

Testing for Web Frameworks Like Django and Flask:

Based on unittest, Django and Flask makes things easier, and they have their testing framework:

 Django Test Runner: The Django startapp template will have created a tests.py file inside your application directory. If you don’t have that already, you can create it with the following contents:

For executing the test suit, we need to give as:

python manage.py test

Use unittest and Flask : Flask requires that the app be imported in file and then set in test mode. You can instantiate a test client and use the test client to make requests to any routes in your application.

All the test client instantiation is done in the setUp() method of your test case. 

Test cases can be executed by using below command (via command line) :

 python -m unittest discover

More Advanced Testing Scenarios:

• Fixture is used which is nothing but the data that is created as an input and reusing them.
• Parameterization can be followed which is nothing but running the same test several times by passing different values and expecting the same result.
• Need to cover different scenarios like handling expected failures, writing integration tests, testing in multiple environments etc.

Below example shows how to write test for bad data type:

Output

.F
======================================================================
FAIL: test_list_tuple_values (__main__.TestSumDifferentPatterns)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "......py", line 10, in test_list_tuple_values
   self.assertEqual(result, 600)
AssertionError: 420 != 600
----------------------------------------------------------------------
Ran 2 tests in 0.001s
FAILED (failures=1)

Automating the Execution of Tests :

Continuous Integration/Continuous Deployment tools are available. They help to run tests, compile, publish and also deploy into production.
https://travis-ci.com/ is one among them which works well with Python and it is an open source project. Login into the site and create.travis.yml with the below contents:

language: python 
python:
<Include the versions as 2.7 or 3.7 whichever required>

install:
– pip install -r <your requirements file>

script: 
– python -m unittest discover

Above file instructs “Travis CI” to look into this file and for given Python versions, the test cases are getting tested by installing the necessary packages as given in the requirements file and finally run below command to run the test.

 python -m unittest discover 

 Results are on the website against your credential

Here we’ll learn how to create a basic test, execute it, and find the bugs before your users do! You’ll learn about the tools available to write and execute tests and also see testing terms like automated, manual, unit and integration tests as well.

Automated vs. Manual Testing 

Unit Tests vs. Integration Tests 

Example for Unit testing:

Output:

Traceback (most recent call last):
 File "....../test_example.py", line 9, in <module>
   test_sum_tuple_values()
 File "...../test_example.py", line 5, in test_sum_tuple_values
   assert sum((100, 200, 200,400)) == 1000, "Result should be 1000"
AssertionError: Result should be 1000

In the above example, We have two methods here and when code is executed, second method throws error as the given values do not produce 1000. 

Choosing a Test Runner: 

Test Runner is a library or a testing tool which reads the source code that contains unit tests and a bunch of settings which can be executed and produces its output to the console or log files. 
There are different Test Runners available in Python. Popular one are 

• unittest
• nose or nose2
• pytest

unittest : It is built into the standard python library.  import unittest should be the starting line of code for using it. Depends upon the python version, it should differ as later versions of Python supports unittest and earlier versions supported unittest2. 
Sample snippet of python code using unittest is given below:

Output:

======================================================================
.F
FAIL: test_xxxxxxx (__main__.TestXXXXX)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "......py", line 8, in test_xxxxxxx
   self.assertEqual(result, 6000)
AssertionError: 600 != 6000
----------------------------------------------------------------------
Ran 1 test in 0.001s
FAILED (failures=1)

nose or nose2: This is an open source application and similar to unittest only.It is compatible with numerous kinds of tests that are written using unittest framework. nose2 is the recent version one, and they are installed by using. 

pip install nose2 

pytest: It supports unittest test cases execution. It has benefits like supporting built in assert statement, filtering of test cases, returning from last failing test etc

No need to write the class, command line entry point etc.,

How to Structure a Simple Test:

1. For writing a test, need to know what is going to get tested.
2. Does it cover unit testing and/or integration testing?
3. All kind of necessary inputs (it can range between integer, float, type data types etc., ) and the code for their execution and get the output and compare the output with expected result.

How to Write Assertions:

Assertion is nothing but validating the output against a known response. i.e. in above code, we have passed the list containing 3 values namely 10, 20 and 30, and we know that its multiplication result is 6000. So as a last step in code, we will be writing assertion code and above code comes up with assertEqual and surely it will give the output as 6000 and hence the testcase passes. 

unittest has lots of methods to assert on the values, types, and existence of variables. 
Let us see few : 

.assertEqual(one,two) means one == two (Our above example) 
.assertTrue(expr) means boolean(expr) is True 
.assertFalse(expr) means boolean(expr) is False 
.assertIs(one,two) means one is two 

We have opposite methods too like:

 .assertIsNot(one,two) means one is not two. 
.assertIsNone(x) vs .assertIsNone(x) 
.assertIn(x, y) vs .assertNotIn(x, y) 
.assertIsInstance(m, n) vs .assertNotIsInstance(m,n) 

Side Effects:

Continuous execution of piece of code has the possibility to alter other things to change like attribute of a class or even a value in the database. So these are need to be decided before doing testing. Refactoring of code needs to be considered to break the side effects and write repeatable and simple unit tests. 

Running Tests From PyCharm:

We can run unittest or pytest by following the steps and this is applicable for running all tests in a directory:

1. First from project tool window, select the tests directory
2. Then, on the context menu, choose “UnitTests in” or “PyTests in “ 
   For individual test,
   • Via main toolbar by using Run or Debug command
   • Via context menu by using Run or Debug by clicking the specific file

Testing for Web Frameworks Like Django and Flask:

Based on unittest, Django and Flask makes things easier, and they have their testing framework:

 Django Test Runner: The Django startapp template will have created a tests.py file inside your application directory. If you don’t have that already, you can create it with the following contents:

For executing the test suit, we need to give as:

python manage.py test

Use unittest and Flask : Flask requires that the app be imported in file and then set in test mode. You can instantiate a test client and use the test client to make requests to any routes in your application.

All the test client instantiation is done in the setUp() method of your test case. 

Test cases can be executed by using below command (via command line) :

 python -m unittest discover

More Advanced Testing Scenarios:

• Fixture is used which is nothing but the data that is created as an input and reusing them.
• Parameterization can be followed which is nothing but running the same test several times by passing different values and expecting the same result.
• Need to cover different scenarios like handling expected failures, writing integration tests, testing in multiple environments etc.

Below example shows how to write test for bad data type:

Output

.F
======================================================================
FAIL: test_list_tuple_values (__main__.TestSumDifferentPatterns)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "......py", line 10, in test_list_tuple_values
   self.assertEqual(result, 600)
AssertionError: 420 != 600
----------------------------------------------------------------------
Ran 2 tests in 0.001s
FAILED (failures=1)

Automating the Execution of Tests :

Continuous Integration/Continuous Deployment tools are available. They help to run tests, compile, publish and also deploy into production.
https://travis-ci.com/ is one among them which works well with Python and it is an open source project. Login into the site and create.travis.yml with the below contents:

language: python 
python:
<Include the versions as 2.7 or 3.7 whichever required>

install:
– pip install -r <your requirements file>

script: 
– python -m unittest discover