Введение в модульное тестирование на Python
Oct 30, 2019 · 5 min read
Вы только что написали фрагмент кода и не знаете, что делать дальше. Отправлять ли pull request, чтобы коллеги провели ревизию кода или же протестировать его вручную?
Конечно же, следует сделать и то, и другое, но с небольшой оговоркой: сначала нужно провести модульное тестирование и убедиться, что код работает, как надо.
Модульные тесты можно пройти или не пройти, и это превращает их в отличный метод для проверки кода. В данной статье я покажу, как писать модульные тесты на Python, и вы увидите, как просто внедрять их в свои проекты.
Начинаем
Функция formatted_name() берет имя и фамилию и соединяет их пробелом между значениями. Таким образом, генерируется полное имя. Затем первая буква каждого слова заменяется на заглавную. Для проверки работоспособности напишите код, который будет использовать данную функцию. В names.py я напишу простой код, который позволит пользователям вводить свои имя и фамилию:
Такой код импортирует formatted_name() из name_function.py и при запуске позволяет пользователям вводить последовательности имен и фамилий. Затем он выдает отформатированные полные имена.
Модульные тесты и сценарии
Тестовый сценарий — это набор модульных тестов, подтверждающих корректность работы функции во всех возможных ситуациях. Тестовый сценарий должен учитывать любые входные значения, которые функция может получить от пользователей. Поэтому необходимо проводить тесты, моделирующие каждую из подобных ситуаций.
Прохождение теста
Вот стандартный сценарий для написания тестов.
Ниже приведено подробное объяснение каждой строки кода:
Падение теста
Чтобы показать вам, как выглядит падение теста, я изменю функцию formatted_name() и добавлю туда аргумент с отчеством. Перепишем функцию следующим образом:
Такая версия formatted_name() работает для пользователей, указавших отчество. Но при тестировании вы увидите, что для людей, не заполнивших это поле, функция выдаст ошибку.
И теперь при запуске функции test_name_function.py результат будет выглядеть вот так:
В этом сообщении вы видите информацию о месте непрохождения теста:
Что делать при падении теста?
Прохождение теста означает, что функция работает, как нужно. Падение теста предвещает вам много «веселья».
Я встречал нескольких программистов, которые предпочитали менять сами тесты, а не дорабатывать код. Не делайте так! Потратьте время на исправление ошибки, ведь так вы лучше поймете свой код и хорошо сэкономите время в дальнейшем.
Изначально для нашей функции formatted_name() требовалось два параметра, а затем, после перезаписи, ей понадобился еще один: отчество. Добавление отчества «сломало » функцию, нарушив ее поведение. И раз уж мы решили исправлять код, а не корректировать тесты, то правильнее будет добавить необязательное поле с отчеством.
После этого нужно убедиться в прохождении тестов в обоих случаях: при указании только имени и фамилии (например, Pete Seeger ), и при указании полного имени с отчеством (например, Raymond Red Reddington ). Давайте еще раз изменим код formatted_name() :
Теперь функция работает для имен с отчеством и без него. Еще раз убедимся, что при прохождении теста мы опять получим Pete Seeger :
Это я и хотел вам показать. Лучше подгонять код под тестирование, а не наоборот. Теперь пора добавить новый тест для имен с отчеством.
Добавление новых тестов
Теперь оба теста пройдены успешно:
Мы написали тесты для проверки работоспособности функции с указанным или отсутствующим отчеством.
Модуль unittest: тестируем свои программы
Представьте, что вы написали какую-либо программу, а теперь хотите проверить, правильно ли она работает. Что вы для этого сделаете? Скорее всего, вы запустите её несколько раз с различными входными данными, и убедитесь в правильности выдаваемого ответа.
А теперь вы что-то поменяли и снова хотите проверить корректность программы. Запускать ещё несколько раз? А если потом снова что-то поменяется? Нельзя ли как-то автоматизировать это дело?
Оказывается, можно. В Python встроен модуль unittest, который поддерживает автоматизацию тестов, использование общего кода для настройки и завершения тестов, объединение тестов в группы, а также позволяет отделять тесты от фреймворка для вывода информации.
Для автоматизации тестов, unittest поддерживает некоторые важные концепции:
Модуль unittest предоставляет богатый набор инструментов для написания и запуска тестов. Однако достаточно лишь некоторых из них, чтобы удовлетворить потребности большинства пользователей.
Вот короткий скрипт для тестирования трех методов строк:
Тестовый случай создаётся путём наследования от unittest.TestCase. 3 отдельных теста определяются с помощью методов, имя которых начинается на test. Это соглашение говорит исполнителю тестов о том, какие методы являются тестами.
Методы setUp() и tearDown() (которые в данном простом случае не нужны) позволяют определять инструкции, выполняемые перед и после каждого теста, соответственно.
Последние 2 строки показывают простой способ запуска тестов. unittest.main() предоставляет интерфейс командной строки для тестирования программы. Будучи запущенным из командной строки, этот скрипт выводит отчёт, подобный этому:
Интерфейс командной строки
unittest может быть использован из командной строки для запуска модулей с тестами, классов или даже отдельных методов:
Можно также указывать путь к файлу:
С помощью флага -v можно получить более детальный отчёт:
Для нашего примера подробный отчёт будет таким:
Обнаружение тестов
unittest поддерживает простое обнаружение тестов. Для совместимости с обнаружением тестов, все файлы тестов должны быть модулями или пакетами, импортируемыми из директории верхнего уровня проекта (см. подробнее о правилах наименования модулей ).
Обнаружение тестов реализовано в TestLoader.discover(), но может быть использовано из командной строки:
Организация тестового кода
Тестовый случай создаётся путём наследования от unittest.TestCase.
Тестирующий код должен быть самостоятельным, то есть никак не зависеть от других тестов.
Простейший подкласс TestCase может просто реализовывать тестовый метод (метод, начинающийся с test). Вымышленный пример:
Заметьте, что для того, чтобы проверить что-то, мы используем один из assert\*() методов.
Тестов может быть много, и часть кода настройки может повторяться. К счастью, мы можем определить код настройки путём реализации метода setUp(), который будет запускаться перед каждым тестом:
Мы также можем определить метод tearDown(), который будет запускаться после каждого теста:
Можно разместить все тесты в том же файле, что и сама программа (таком как widgets.py), но размещение тестов в отдельном файле (таком как test_widget.py) имеет много преимуществ:
Пропуск тестов и ожидаемые ошибки
unittest поддерживает пропуск отдельных тестов, а также классов тестов. Вдобавок, поддерживается пометка теста как «не работает, но так и надо».
Пропуск теста осуществляется использованием декоратора skip() или одного из его условных вариантов.
Классы также могут быть пропущены:
Ожидаемые ошибки используют декоратор expectedFailure():
Очень просто сделать свой декоратор. Например, следующий декоратор пропускает тест, если переданный объект не имеет указанного атрибута:
Декораторы, пропускающие тесты или говорящие об ожидаемых ошибках:
Для пропущенных тестов не запускаются setUp() и tearDown(). Для пропущенных классов не запускаются setUpClass() и tearDownClass(). Для пропущенных модулей не запускаются setUpModule() и tearDownModule().
Различение итераций теста с помощью подтестов
Когда некоторые тесты имеют лишь незначительные отличия, например некоторые параметры, unittest позволяет различать их внутри одного тестового метода, используя менеджер контекста subTest().
Например, следующий тест:
даст следующий отчёт:
Без использования подтестов, выполнение будет остановлено после первой ошибки, и ошибку будет сложнее диагностировать, потому что значение i не будет показано:
Проверки на успешность
Модуль unittest предоставляет множество функций для самых различных проверок:
assertTrue(x) — bool(x) is True
assertFalse(x) — bool(x) is False
assertIsNot(a, b) — a is not b
assertIsNone(x) — x is None
assertIsNotNone(x) — x is not None
assertNotIn(a, b) — a not in b
assertIsInstance(a, b) — isinstance(a, b)
assertNotIsInstance(a, b) — not isinstance(a, b)
assertRaises(exc, fun, *args, **kwds) — fun(*args, **kwds) порождает исключение exc
assertRaisesRegex(exc, r, fun, *args, **kwds) — fun(*args, **kwds) порождает исключение exc и сообщение соответствует регулярному выражению r
assertWarns(warn, fun, *args, **kwds) — fun(*args, **kwds) порождает предупреждение
assertWarnsRegex(warn, r, fun, *args, **kwds) — fun(*args, **kwds) порождает предупреждение и сообщение соответствует регулярному выражению r
assertAlmostEqual(a, b) — round(a-b, 7) == 0
assertGreaterEqual(a, b) — a >= b
Юнит-тесты на Python: Быстрый старт
Перевод статьи подготовлен специально для студентов курса «Python QA Engineer».
Юнит-тестирование кода является неотъемлемой частью жизненного цикла разработки программного обеспечения. Юнит-тесты также формируют основу для проведения регрессионного тестирования, то есть они гарантируют, что система будет вести себя согласно сценарию, когда добавятся новые функциональные возможности или изменятся существующие.
В этой статье я продемонстрирую основную идею юнит-тестирования на одном классе. На практике вам придется писать множество тестовых случаев, добавлять их в тестовый набор и запускать все вместе. Управление тест-кейсами мы рассмотрим в следующей статье.
Сегодня мы сосредоточимся на тестировании бэкенда. То есть разработчик реализовал некоторый проект согласно спецификациям (например, Calculator.py), а ваша задача состоит в том, чтобы убедиться, что разработанный код действительно им соответствует (например, с помощью TestCalculator.py ).
Предположим, что вы написали класс Calculator для выполнения основных вычислительных функций: сложения, вычитания, умножения и деления.
Код для этого здесь ( Calculator.py ):
Теперь я хочу запустить юнит-тест, чтобы понять, что функциональность в приведенном выше классе работает, как запланировано.
Юнит-тест имеет следующую структуру:
setUp() и tearDown() – это стандартные методы, которые поставляются с фреймворком unittest (они определены в классе unittest.TestCase). В зависимости от вашего тестового случая вы можете переопределять или не переопределять два этих метода по умолчанию.
Всякий раз, когда выполняется этот тест-кейс, сначала выполняется метод setUp(). В нашем случае мы просто создаем объект класса Calculator и сохраняем его как атрибут класса. В родительском классе есть несколько других методов по умолчанию, которые мы рассмотрим позже.
Вы увидите вывод, сходный со следующим:
Что делать, если что-то не работает, как ожидалось? Давайте изменим ожидаемое значение test_divide с 5 на 6 (5 – правильное значение, сейчас мы посмотрим, что случится при сбое. Это не ошибка в исходном коде, а ошибка в тестовом наборе, у вас тоже могут быть ошибки в тестовых наборах, поэтому всегда проверяйте тестовые сценарии на наличие ошибок!)
При запуске этого тест-кейса, вы получите следующий результат:
Здесь написано, что 3 из 4 тестов прошли успешно, а один не удался. В реальном сценарии, предполагается, что ваш тестовый случай является верным, то есть таким образом он помогает определять неправильно реализованную функцию.
Как писать профессиональные модульные тесты на Python
Тестирование, это основа серьёзной разработки программного обеспечения. Существует много видов тестирования, но наиболее важный вид, это модульное тестирование. Модульное тестирование даёт уверенность в том, что вы сможете использовать хорошо протестированные блоки в качестве базовых элементов, полагаться на них и использовать при создании программы. Они увеличивают ваш инструментарий из проверенного кода за пределами ваших конструкций и стандартной библиотеки. Кроме того Python предоставляет отличную поддержку для написания модульных тестов.
Действующий пример
Прежде чем погрузиться в принципы, эвристики и руководства, давайте посмотрим репрезентативный модульный тест в действии. Класс SelfDrivingCar это частичное выполнение логики вождения автопилота автомобиля. Главным образом он контролирует скорость автомобиля. Он рспознаёт объекты впереди, ограничение скорости, а также прибытие или нет в пункт назначения.
Вот модульный тест для метода stop() чтобы раззадорить ваш аппетит. Я расскажу подробности позже.
Руководство по модульному тестированию
Основные идеи
Написание хороших модульных тестов это тяжелый труд. Написание модульных тестов занимает время. Когда вы меняете код, необходимо изменять тесты. Иногда в вашем тесте будут ошибки. Это означает, что вы должны быть по-настоящему идейным. Польза огромна, даже для небольших проектов, но это не бесплатно.
Будьте дисциплинированы
Вы должны быть дисциплинированным. Будьте последовательным. Убедитесь, что все тесты выполнены. Не отказывайтесь от тестов, только потому что вы «знаете», что код в порядке.
Автоматизируйте
Чтобы помочь вам быть дисциплинированным, необходимо автоматизировать модульные тесты. Тесты должны запускаться автоматически на значимых этапах, таких как проектирование или развертывание. В идеале ваша система управления версиями должна отклонять код, который не прошел все тесты.
Непротестированный код плохой по определению
Если вы не проверили его, вы не сможете сказать, что он работает. Это значит, что вы должны рассматривать его как плохой. Если это критический код, не разворачивайте его в производство.
Пояснения
Что такое модуль?
Модуль в смысле тестирования это файл, содержащий набор определённых функций или класс. Если у вас есть файл с несколькими классами, вы должны написать модульный тест для каждого из них.
Делать TDD или не делать TDD
Тест драйв разработка, это практика, где вы пишете тесты, до того как вы пишете код. Есть несколько преимуществ этого подхода, но я рекомендую отказаться от него, если у вас есть возможность написать тесты позже.
Причина заключается в том, что я проектирую код. Я пишу код, смотрю на него, переписываю, еще раз смотрю и быстро переписываю ещё раз. Написание тестов сначала ограничивает и замедляет меня.
После того, как я сделаю первоначальный дизайн, я сразу напишу тесты, до интеграции со всей системой. Тем не менее, это отличный способ найти себя в создании модульных тестов, и это гарантирует, что весь ваш код будет проверен.
Unittest модуль
Следующий шаг — написать специфические методы теста для тестирования кода внутри теста — в этом случае класс SelfDrivingCar — делает то, что он должен делать. Структура тестового метода довольно обычная:
Обратите внимание, что результат не должен быть результатом метода. Он может быть изменением состояния класса, сторонним эффектом, например как добавление новой строки в базе данных, записью файла или отправкой сообщения по электронной почте.
Здесь на самом деле два теста. Первый тест, чтобы убедиться, что если скорость автомобиля равна 5 и stop() вызывается, то скорость становится равна 0. И еще один тест, чтобы убедиться, что ничего не случится, если вызвать stop() снова, когда автомобиль уже остановился.
Позже я расскажу о других тестах для дополнительных функциональных возможностей.
Doctest модуль
Doctest модуль очень интерестный. Он позволяет использовать интерактивные примеры в docstring и проверять результаты, включая исключения.
Как вы видите, docstring намного больше, чем код функции. Это не улучшает читаемость кода.
Запуск тестов
OK. Вы написали модульные тесты. Для большой системы у вас будет десятки / сотни / тысячи модулей и классов, возможно,размещенных в разных папках. Как вы будете запускаете все тесты?
Чтобы найти и запустить тесты на основе unittest, просто введите в командной строке:
Существует несколько флагов, которые управляют операцией:
Определение степени покрытия кода
Если оба являются строками, то он пытается преобразовать их в целые числа и добавить. В противном случае он вызывает исключение. Функция test_add() проверяет функцию add() с аргументами, которые являются как целыми числами, так и аргументами, которые являются плавающим значением и проверяют правильное поведение в каждом случае. Но степень покрытия теста является незавершенной. В случае, если строковые аргументы были не протестированы. В результате тест проходит успешно, но ошибка в ветке, где аргументы были строками, не были обнаружены (см. «intg»?).
Практические Unit Tests
Написание тестов промышленной мощности нелегкая и непростая задача. Есть несколько вещей, которые нужно учитывать и компромиссы, на которые следует пойти.
Разработка тестирования
Затраты и выгоды
Количество усилий, которые вы вкладываете в тестирование, должно быть сопоставимо с затратами на неудачу, насколько стабильным является код и насколько легко его можно исправить, если проблемы обнаружены в строке.
С другой стороны, если одна кнопка в вашем веб-приложении на странице, которая расположена тремя уровнями ниже главной страницы, немного мерцает, когда кто-то ее щелкает, вы можете это исправить, но, вероятно, вы не будете добавлять отдельный модульный тест для этого случая. Данный метод не оправдывает себя экономически.
Мышление тестирования
Мышление тестирования очень важно. Один из принципов, который я использую, состоит в том, что каждый кусок кода имеет как минимум двух пользователей: код, который использует его, и пользователь, который его тестирует. Это простое правило помогает с разработкой и зависимостей. Если вы помните, что вам нужно написать тест для своего кода, вы не добавите много зависимостей, которые трудно восстановить во время тестирования.
Например, предположим, что ваш код должен что-то вычислять. Для этого ему необходимо загрузить данные из базы, прочитать файл конфигурации и динамически обратиться к некоторыми REST API для получения актуальной информации. Все это может потребоваться по разным причинам, но при этом, ели вы разместите всё это в одной функции, это очень затруднит тестирование. Это возможно звучит смешно, но гораздо лучше изначально структурировать ваш код.
Чистые функции
Почему их легко проверить? Потому что нет необходимости устанавливать специальную среду для их тестирования. Вы просто передаете аргументы и проверяете результат. Вы также знаете, что до тех пор, пока тестируемый код не изменится, ваш тест тоже не должен изменяться.
Сравните его с функцией, которая считывает XML-файл конфигурации. Ваш тест должен будет создать XML-файл и передать его имя файла в тестируемый код. Не трудная задача. Но предположим, что кто-то решил, что XML просто ужасен, и все файлы конфигурации должны находиться в JSON. Они занимаются своим делом и конвертируют все файлы конфигурации в JSON. Они проводят все тесты, включая ваши, и все они успешно завершаются!
Почему? Потому что код не изменился. Он все еще ожидает файл конфигурации XML, и ваш тест по-прежнему создает XML-файл для него. Но при выполнении ваш код получит файл JSON, который он не сможет проанализировать.
Обработка ошибок тестирования
Как правило, вы хотите проверить ввод в общедоступном интерфейсе, потому что вам не обязательно знаеть, кто будет обращаться к вашему коду. Давайте посмотрим на метод drive() автопилота автомобиля. Этот метод ожидает параметр «destination». Параметр «destination» будет использоваться позже в навигации, но метод «drive» ничего не делает, чтобы мы смогли убедиться в его корректности.
Чтобы проверить, как обработались ошибки в тесте, я передаю неверные аргументы и думаю, что они должным образом будут отвергнуты. Вы можете сделать это, используя self.assertRaises() метод unittest.TestCase. Этот метод очень удачный, если код под тестированием действительно вызывает исключение.
Давайте посмотрим на это в действии. Метод test_drive() пропускает широту и долготу вне допустимого диапазона и ждет, что метод drive() вызовет исключение.
Тест не выполняется, поскольку метод drive () не проверяет его аргументы на достоверность и не вызывает исключения. Вы получите хороший отчет с полной информацией о том, что не удалось, где и почему.
Теперь все тесты проходят.
Тестирование частных методов
Должны ли вы проверять каждую функцию и метод? В частности, следует ли тестировать частные методы, называемые только вашим кодом? Обычный неудовлетворительный ответ: «В зависимости от ситуации».
Как организовать ваши модульные тесты
В большой системе не всегда ясно, как провести тесты. Должен ли быть один большой файл со всеми тестами для пакета или отдельный тестовый файл для каждого класса? Должны ли тесты быть в том же файле, что и тестируемый код, или в том же каталоге?
Этот подход имеет ряд преимуществ. Это дает определённость уже при просмотре каталогов, сразу видно, что вы не забыли протестировать. Это также помогает сохранять тесты в приемлимых размерах. Предполагая, что ваши модули имеют приемлимый размер, тестовый код для каждого модуля будет в собственном файле, который может быть немного больше, чем тестируемый модуль, но все же удобно размещён в одном файле.
Заключение
Юнит- тесты являются основой качествнного кода. В этом уроке я изучил некоторые принципы и рекомендации для работы с модульным тестированием и объяснил нескольких лучших практик. Чем больше система, которую вы строите, тем более важными становятся модульные тесты. Но одних модульных тестов недостаточно. Другие типы тестов также необходимы для крупномасштабных систем: интеграционные тесты, тесты производительности, тесты нагрузки, тестирование на уязвимость, тесты на прием данных и другие.
Знакомство с тестированием в Python. Ч.1
От нашего стола к вашему. То есть от нашего курса «Разработчик Python», несмотря на стремительно приближающий Новый год, мы подготовили вам интересный перевод о различных методах тестирования в Python.
Это руководство для тех, кто уже написал классное приложение на Python, но еще не писал для
них тесты.
Тестирование в Python — обширная тема с кучей тонкостей, но не обязательно все усложнять. В несколько простых шагов можно создать простые тесты для приложения, постепенно наращивая сложность на их основе.
В этом руководстве вы узнаете, как создать базовый тест, выполнить его и найти все баги, до того как это сделают пользователи! Вы узнаете о доступных инструментах для написания и выполнения тестов, проверите производительность приложения и даже посмотрите на проблемы безопасности.
Тестирование Кода
Тестировать код можно разными способами. В этом руководстве вы познакомитесь с методами от наиболее простых до продвинутых.
Автоматизированное vs. Ручное Тестирование
Хорошие новости! Скорее всего вы уже сделали тест, но еще не осознали этого. Помните, как вы впервые запустили приложение и воспользовались им? Вы проверили функции и поэкспериментировали с ними? Такой процесс называется исследовательским тестированием, и он является формой ручного тестирования.
Исследовательское тестирование — тестирование, которое проводится без плана. Во время исследовательского тестирования вы исследуете приложение.
Чтобы создать полный список мануальных тестов, достаточно составить перечень всех функций приложения, различных типов ввода, которые оно принимает, и ожидаемые результаты. Теперь, каждый раз когда вы меняете что-то в коде, нужно заново проверять каждый из элементов этого списка.
Звучит безрадостно, верно?
Поэтому нужны автоматические тесты. Автоматическое тестирование — исполнение плана тестирования (части приложения, требующие тестирования, порядок их тестирования и ожидаемые результаты) с помощью скрипта, а не руками человека. В Python уже есть набор инструментов и библиотек, которые помогут создать автоматизированные тесты для вашего приложения. Рассмотрим эти инструменты и библиотеки в нашем туториале.
Модульные Тесты VS. Интеграционные Тесты
Мир тестирования полон терминов, и теперь, зная разницу между ручным и автоматизированным тестированием, опустимся на уровень глубже.
Подумайте, как можно протестировать фары машины? Вы включаете фары (назовем это шагом тестирования), выходите из машины сами или просите друга, чтобы проверить, что фары зажглись (а это — тестовое суждение). Тестирование нескольких компонентов называется интеграционным тестированием.
Подумайте о всех вещах, которые должны правильно работать, чтобы простая задача выдала корректный результат. Эти компоненты похожи на части вашего приложения: все те классы, функции, модули, что вы написали.
Главная сложность интеграционного тестирования возникает, когда интеграционный тест не дает правильный результат. Сложно оценить проблему, не имея возможности изолировать сломанную часть системы. Если фары не зажглись, возможно лампочки сломаны. Или может аккумулятор разряжен? А может проблема в генераторе? Или вообще сбой в компьютере машины?
Современные машины сами оповестят вас о поломке лампочек. Определяется это с помощью модульного теста.
Модульный тест (юнит-тест) — небольшой тест, проверяющий корректность работы отдельного компонента. Модульный тест помогает изолировать поломку и быстрее устранить ее.
Мы поговорили о двух видах тестов:
Значения правильные, поэтому в REPL ничего не будет выведено. Если результат sum() некорректный, будет выдана AssertionError с сообщением “Should be 6” (“Должно быть 6”). Проверим оператор утверждения еще раз, но теперь с некорректными значениями, чтобы получить AssertionError :
Вместо REPL, положите это в новый Python-файл с названием test_sum.py и выполните его снова:
Теперь у вас есть написанный тест-кейс (тестовый случай), утверждение и точка входа (командной строки). Теперь это можно выполнить в командной строке:
Вы видите успешный результат, “Everything passed” (“Все пройдено”).
sum() в Python принимает на вход любой итерируемый в качестве первого аргумента. Вы проверили список. Попробуем протестировать кортеж. Создадим новый файл с названием test_sum_2.py со следующим кодом:
Можно увидеть, как ошибка в коде вызывает ошибку в консоли с информацией, где она произошла, и каким был ожидаемый результат.
Такие тесты подойдут для простой проверки, но что если ошибки есть больше, чем в одном? На помощь приходят исполнители тестов (test runners). Исполнитель тестов — особое приложение, спроектированное для проведение тестов, проверки данных вывода и предоставления инструментов для отладки и диагностики тестов и приложений.
Выбор Исполнителя Тестов
Для Python доступно множество исполнителей тестов. Например, в стандартную библиотеку Python встроен unittest. В этом руководстве, будем использовать тест-кейсы и исполнители тестов unittest. Принципы работы unittest легко адаптируются для других фреймворков. Перечислим самые популярные исполнители тестов:
unittest встроен в стандартную библиотеку Python, начиная с версии 2.1. Вы наверняка столкнетесь с ним в коммерческих приложениях Python и проектах с открытым исходным кодом.
В unittest есть тестовый фреймворк и исполнитель тестов. При написании и исполнении тестов нужно соблюдать некоторые важные требования.
Чтобы превратить ранее написанный пример в тест-кейс unittest, необходимо:
Таким образом, вы выполнили два теста с помощью исполнителя тестов unittest.
Примечание: Если вы пишете тест-кейсы для Python 2 и 3 — будьте осторожны. В версиях Python 2.7 и ниже unittest называется unittest 2. При импорте из unittest вы получите разные версии с разными функциями в Python 2 и Python 3.
Чтобы узнать больше о unittest’ах почитайте unittest документацию.
Со временем, после написания сотни, а то и тысячи тестов для приложения, становится все сложнее понимать и использовать данные вывода unittest.
nose совместим со всеми тестами, написанными с unittest фреймворком, и может заменить его тестовый исполнитель. Разработка nose, как приложения с открытым исходным кодом, стала тормозиться, и был создан nose2. Если вы начинаете с нуля, рекомендуется использовать именно nose2.
Для начала работы с nose2 нужно установить его из PyPl и запустить в командной строке. nose2 попытается найти все тестовые скрипы с test*.py в названии и все тест-кейсы, унаследованные из unittest.TestCase в вашей текущей директории:
pytest поддерживает выполнение тест-кейсов unittest. Но настоящее преимущество pytest — его тест-кейсы. Тест-кейсы pytest — серия функций в Python-файле с test_ в начале названия.
Есть в нем и другие полезные функции:
Вы избавились от TestCase, использования классов и точек входа командной строки.
Больше информации можно найти на Сайте Документации Pytest.
Написание Первого Теста
Объединим все, что мы уже узнали, и вместо встроенной функции sum() протестируем простую реализацию с теми же требованиями.
Структура папок будет выглядеть так:
project/
│
└── my_sum/
└── __init__.py
При использовании __import__() вам не придется превращать папку проекта в пакет, и вы сможете указать имя файла. Это полезно, если имя файла конфликтует с названиями стандартных библиотек пакетов. Например, если math.py конфликтует с math модулем.
Как Структурировать Простой Тест
Перед написанием тестов, нужно решить несколько вопросов:
Код в этом примере:
Как Писать Утверждения
Последний шаг в написании теста — проверка соответствия выходных данных известным значениям. Это называют утверждением (assertion). Существует несколько общих рекомендаций по написанию утверждений:
| Метод | Эквивалент |
|---|---|
| .assertEqual(a, b) | a == b |
| .assertTrue(x) | bool(x) is True |
| .assertFalse(x) | bool(x) is False |
| .assertIs(a, b) | a is b |
| .assertIsNone(x) | x is None |
| .assertIn(a, b) | a in b |
| .assertIsInstance(a, b) | isinstance(a, b) |
Писать тесты сложнее, чем просто смотреть на возвращаемое значение функции. Зачастую, выполнение кода меняет другие части окружения: атрибуты класса, файлы файловой системы, значения в базе данных. Это важная часть тестирования, которая называется побочные эффекты. Решите, тестируете ли вы побочный эффект до того, как включить его в список своих утверждений.
Если вы обнаружили, что в блоке кода, который вы хотите протестировать, много побочных эффектов, значит вы нарушаете Принцип Единственной Ответственности. Нарушение принципа единственной ответственности означает, что фрагмент кода делает слишком много вещей и требует рефакторинга. Следование принципу единственной ответственности — отличный способ проектирования кода, для которого не составит труда писать простые повторяемые модульные тесты, и, в конечном счете, создания надежных приложений.
Запуск Первого Теста
Вы создали первый тест и теперь нужно попробовать выполнить его. Понятно, что он будет пройден, но перед созданием более сложных тестов, нужно убедиться, что даже такие тесты выполняются успешно.
Запуск Исполнителей Тестов
Исполнитель тестов — приложение Python, которое выполняет тестовый код, проверяет утверждения и выдает результаты тестирования в консоли. В конец test.py добавьте этот небольшой фрагмент кода:
Другой способ — использовать командную строку unittest. Попробуем:
Мы исполнили один тест из test.py и вывели результаты в консоль. Многословный режим перечислил имена выполненных тестов и результаты каждого из них.
Вместо предоставления имени модуля, содержащего тесты, можно запросить авто-обнаружение при помощи следующего:
Эта команда будет искать в текущей директории файлы с test*.py в названии, чтобы протестировать их.
Понимание Результатов Тестирование
Это был очень простой пример, где все прошло успешно, поэтому попробуем понять выходные данные проваленного теста.
sum() должен принимать на вход другие списки числового типа, например дроби.
К началу кода в файле test.py добавьте выражение для импорта типа Fraction из модуля fractions стандартной библиотеки.
Теперь добавим тест с утверждением, ожидая некорректное значение. В нашем случае, ожидаем, что сумма ¼, ¼ и ⅖ будет равна 1:
В этих выходных данных вы видите следующее:
Запуск тестов из PyCharm
Если вы используете PyCharm IDE, то можете запустить unittest или pytest, выполнив следующие шаги:
Больше информации доступно на сайте 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) и домашней директории (.).
По завершении настройки, вы увидите статус тестов в нижней части экрана и сможете быстро получить доступ к тестовым логам и повторно запустить тесты, кликнув по иконкам:
Видим, что тесты выполняются, но некоторые из них провалены.
В следующей части статьи мы рассмотрим тесты для фреймворков, таких как Django и Flask.
Ждём ваши вопросы и комментарии тут и, как всегда, можно зайти к Станиславу на день открытых дверей.