Модульные / функциональные тесты!

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

Что такое модульный тест?

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

Как обычно выполняется один из моих тестов [в маркированной форме]:

  1. Тест инициализируется
  2. Тест выполняет сегмент кода приложения
  3. Тест ожидает, что результатом сегмента кода приложения будет некоторое значение.
  4. Если результат соответствует ожиданиям, вы получите зеленые буквы в своем терминале.
  5. Если результат не такой, как ожидалось, вы увидите красные буквы в своем терминале с информацией о непройденном тесте.

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

Тестирование кода устраняет ошибки на ранней стадии

Я часто пишу код с ошибками. Если и есть какой-то ген, дающий людям дар безупречного написания кода, то у меня его нет.

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

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

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

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

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

Теперь я могу управлять своим проектом с помощью тестов

До TDD я тестировал только небольшую часть кода, который написал, и написал довольно ужасные тесты. Мои тесты были плохими, потому что тестировать уже существующий код сложнее, чем писать код, соответствующий ожиданиям.

После TDD я тестирую примерно 95% кода, который пишу, и мои тесты гораздо менее ужасны!

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

Сценарий

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

И это все!

  • Отказ от ответственности: использовать тест для проверки дня недели — плохая идея. Это как проверить, не 9:30 ли это. Очень маловероятно, что сейчас 9:30 утра, поэтому писать тест, подтверждающий, что это так, бесполезно. И этот тест почти всегда терпел неудачу! Я сделал это, чтобы быть китчевым из-за названия блога!
  • Кроме того! В этом примере, поскольку я проверяю поведение модуля в приложении, это функциональный тест, а не настоящий модульный тест. Спасибо, u/b1ackcat!

Возможно, входящие мнения, вызывающие ярость:
 я рекомендую использовать pytest для тестирования кода при первом запуске и, возможно, всегда. Unittest имеет массу функций, но также имеет очень жесткую структуру, которая может показаться немного сложной и потенциально препятствовать использованию TDD.

Простота pytest, а также удобная для чтения документация делают его победителем моей награды Скромное мнение программистов.

pytest необходимо установить с помощью pip3. Он не входит в стандартную комплектацию моей копии Python 3.

В терминале:

pip3 install pytest

потом

py.test whatever_your_test_is_named.py

Давайте посмотрим код:

Сегодняшнее решение — это пока самый простой код задач. Это потому, что я хотел подчеркнуть важность тестов для выявления регрессий и улучшения структуры кода за счет реализации TDD.

На самом деле в программе происходят только две вещи

  1. Поведение функции определено
  2. Утверждают с проверкой, что на самом деле сегодня пятница. Если сегодня пятница, компьютер наградит вас красивыми зелеными буквами в терминале. Если это НЕ пятница, компьютер выражает гнев красными буквами в терминале.

И да, вам не нужно отмечать пятницу, я просто стараюсь оставаться на связи с брендом!

Личный вынос

  1. Мне очень нравится питест. Я уверен, что в конечном итоге мне понравится unittest, потому что он может имитировать, но сейчас я собираюсь изучить его и определить, понадобится ли он мне для какого-либо кода, который я буду писать.
  2. Модуль datetime довольно приятный, и он встроен прямо в программу. Еще одна крутая особенность языка, которая поддерживает менталитет «Давайте поработаем».

В заключение

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

Примечание: сегодня нет источников из Stack Overflow. Я не знаю, успех это или нет… И до написания этой статьи и получения отзывов я понятия не имел, в чем разница между функциональным тестом и модульным тестом!

Спасибо за чтение! Если вам понравилось, поставьте ❤!

Также спасибо сообществам r/learnpython и r/python на Reddit за чтение и помощь в этом процессе обучения!