Как сделать тест на питоне
Юнит-тесты на 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
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 :
Это я и хотел вам показать. Лучше подгонять код под тестирование, а не наоборот. Теперь пора добавить новый тест для имен с отчеством.
Добавление новых тестов
Теперь оба теста пройдены успешно:
Мы написали тесты для проверки работоспособности функции с указанным или отсутствующим отчеством.
Python. Генерация юнит-тестов
Только ленивый ещё не писал о необходимости писать тесты. Но давайте признаемся честно — писать тесты зачастую скучно. Особенно для legacy-кода. Сотни повторяющихся, однообразных строк. Скука. Что с этим можно сделать?
Картинка для привлечения внимания. Красивый питон, да? (Автор фото: Paweł Stefaniak)
Pythoscope
К сожалению, у stable-ветки проблемы с юникодом. Для тестовых целей сойдет и она, но для реального применения лучше воспользоваться dev-веткой, благо она работает стабильно:
Протестируем кота
Что бы тестировать кота, нам сначала собственно нужен кот. Напишем его:
Теперь перейдем в папку с cat.py и инициализируем Pythoscope:
У нас появилась папка tests с вложенным cat_test.py. В котором… Почти ничего нет:
Негусто? Ну, по крайней мере теперь есть каркас, который будет экономить нам время при написании тестов.
Как выяснилось, магии не бывает — тесты сами не напишутся. Но не всё потеряно, мы можем помочь Pythoscope понять, что запускать для тестов. Для этого реализавны, так называемые «точки входа» (points of entry) — некие use-case использования нашего кода.
Напишем points of entry для нашего котэ:
Запустим еще раз генерацию тестов:
Теперь лучше, к тестовому классу добавился метод который действительно что-то тестирует:
А что если подсунуть котэ не рыбу? Ошибка? Надо и это проверить:
Отлично, осталось лишь проверить:
Превосходно! Удачного и легкого тестирования!
Как сделать тест на питоне
B прошлой статье мы рассказывали о организации модулей Python, особенно полезных для крупных Data Science проектов. В этот раз поговорим о модульном тестировании (unit testing): читайте в нашей статье о том, как писать и запускать тесты для проверок функций и как в стандартной библиотеке Python применяется один из главных принципов разработки ПО — DRY (don’t repeat yourself).
Пишем простые тесты для функций модуля
Список методов для проверки на ожидаемое соответствие
Запуск unit-тестов
Для запуска тестов нужно написать в командой строке следующее:
Тогда запуск осуществляется простой командой:
Проваленные тесты
Попробуем заменить некоторые значения так, что ожидаемый результат не будет сходиться с вычислениями, например, изменим тест с проверкой на положительное число:
Тестирование исключений
На практике может возникнуть ситуация, когда функция содержит исключение, срабатываемое при определенных условиях. Их тоже можно проверять, ведь, если функция Python поднимает исключение при ожидаемом результате, значит, она работает корректно.
Добавим в файл с вычислениями ещё одну функцию деления одного числа на другое. Понятно, что делить на 0 невозможно, поэтому функция поднимает соответствующее исключение:
Тогда для проверки исключений рекомендуется использовать контекстный менеджер Python, внутри которого просто вызвать проверяемую функцию:
Операции перед проведением тестов
В следующей статье поговорим о продвинутых темах модульного тестирования. А о том, как писать тесты в реальных проектах Data Science, вы узнаете на наших Python-курсах в лицензированном учебном центре обучения и повышения квалификации IT-специалистов в Москве.
Тестирование. Начало
Привет. В этой серии постов я попробую рассказать про тестирование кода на питоне, в частности проектов django. Мы рассмотрим модульное тестирование (юнит-тесты), статический анализ кода и некоторые подводные камни тестирования веб-сайтов.
Вводную часть о пользе тестирования опустим — код, покрытый тестами, становится мягким и шелковистым, про это только ленивый еще не читал / писал.
unittest
Как эта штука работает. Предположим, у нас есть нечеловечески сложный модуль, run_once.py:
(Это декоратор, который сохраняет результат первого вызова функции-параметра и всегда возвращает сохраненное значение.)
Тест нашего модуля может выглядеть как-то так:
Последние две строки представляют собой пускалку, которая найдет и запустит все тесты в этом модуле. Теперь в консоли мы можем выполнить
И пронаблюдать результат тестирования:
doctest
Поскольку юнит-тестами в наши дни никого не удивишь, покажу одну штуку, специфичную для питона — доктесты (doctests). Это действительно проще показать, чем объяснить:
Мы видим, что docstring функции превратился в пример кода, одинаково понятный (надеюсь) и разработчику, и интерпретатору.
По сравнению с классическими юнит-тестами, у доктестов есть как плюсы (простота написания, можно скопировать прямо из интерактивной сессии питона; документация всегда соответствует коду), так и минусы (сложный код быстро становится нечитаемым; текстовый редактор не подсветит такой код, а статический анализатор не найдет в нем ошибок). Впрочем, ничто не мешает применять докстесты для мелких очевидных вещей (как в примере), и юнит-тесты для более сложных задач.
py.test
Наряду с входящими в стандартную поставку питона средствами, существуют и альтернативные инструменты, например, py.test. Инсталляция происходит как обычно,
Возьмем функцию из первого примера. Видоизмененный юнит-тест будет выглядеть как-то так:
У отсутствия API, впрочем, есть и обратная сторона: новый разработчик, подключившись к проекту, может просто не понять, как запустить этот ворох функций. Впрочем, настолько новым разработчик пробудет совсем недолго, а способ запуска тестов лучше в любом случае документировать, от греха подальше.
За сим откланиваюсь. Осталось только приложить исходники примеров, три штуки. Public domain.
В следующем выпуске: штатные средства тестирования django и как с ними бороться.