Написание модульных тестов с помощью PHPUnit, часть 2: разборка
В конце прошлого месяца я начал говорить о написании модульных тестов в PHPUnit для кода на основе WordPress. В первую очередь это включало идею настройки PHPUnit, функции setUp и написания базовых тестов.
Это, однако, не обсуждало то, что я знаю о функции tearDown, которая по-прежнему является важной особенностью написания с использованием тестов. Кроме того, есть два способа рассмотреть возможность написания тестов для проектов WordPress.
А именно:
- написание тестов специально для плагинов и функциональности прикладного уровня,
- запуск модульных тестов для приложения WordPress.
Однако, прежде чем двигаться дальше с этим конкретным постом, я рекомендую наверстать упущенное. Сюда входят следующие посты:
- Среда разработки WordPress (с использованием диспетчера пакетов)
- IDE для разработки WordPress
- Работа с пользовательскими настройками в Visual Studio Code
- Написание модульных тестов с помощью PHPUnit, часть 1: настройка
Как только вы это сделаете, вернитесь к этому посту и давайте продолжим обсуждение функции tearDown и того, как на самом деле выглядят модульные тесты в контексте WordPress.
Модульные тесты с PHPUnit, часть 2: разборка
Прежде чем двигаться дальше, помните, что разработчики часто рассматривают функцию setUp как конструктор, а функцию tearDown — как деструктор; однако помните, что последнее не всегда нужно.
Вот хорошее практическое правило, которое следует запомнить:
- Все, что нужно тестовой функции, вызовет функцию setUp, поэтому необходимы необходимые классы.
- Функция tearDown не всегда нужна, так как функция setUp может повторно инициализировать класс.
Так что же это означает для функции tearDown, если она не сбрасывает данные, созданные во время функции setUp?
1 Функция разрыва
Лучший совет, который я могу дать по поводу функции tearDown, заключается в том, что ее следует использовать, если во время одного из оставшихся тестов что-то настроено.
Это может быть запись в базу данных, запись в журнал или, в более общем случае, запись на жесткий диск.
Таким образом, если тест записывает запись или файл, метод tearDown запускается после теста и должен удалить все, что записано тестом на диск, что не является частью теста, но не требуется постоянно для следующего теста или что надо убирать за собой.
Так что в некотором смысле это похоже на деструктор, но если вы никогда не использовали язык, в котором есть деструктор, эта номенклатура либо кажется неуместной, либо не имеет смысла.
Деструктор — это специальная функция -член, которая вызывается, когда время жизни объекта заканчивается. Цель деструктора — освободить ресурсы, которые объект мог получить за время своего существования.
Таким образом, возможно, лучше просто думать о функции как о способе очистки после теста (а не в смысле установки переменной равной нулю, поскольку функция setUp может это сделать).
2 модульных теста для проектов WordPress
При написании модульных тестов для проектов WordPress мы должны убедиться, что четко понимаем, о каком типе модульных тестов мы говорим.
Например, то, что я буду называть классическими или стандартными модульными тестами, следует методологии «разработки через тестирование», о которой я расскажу чуть позже. С другой стороны, WordPress имеет собственный набор модульных тестов для тем и тому подобного, о котором я также расскажу чуть позже в этом посте.
Но в этом разделе я подумал, что было бы полезно немного поговорить о первом, а не о втором, чтобы вы могли увидеть, как это может работать.
В приведенном ниже примере я пишу тесты для плагина, который отвечает за связь со сторонним API. Для этого конкретного плагина требуется имя пользователя и пароль или API, и мы хотим убедиться, что для целей этого поста он правильно извлекает ошибку при каждом запуске теста.
Обратите внимание, что при чтении этого кода вы увидите, как я немного расскажу об отражении. Скоро я собираюсь написать целую статью о PHP Reflection, чтобы пролить свет на это.
Однако для приведенного ниже кода предположим, что это способ, с помощью которого мы можем получить доступ к свойствам, которые в противном случае помечены как частные.
Напомним, что в последнем посте этой серии у нас был начальный тест, который выглядел так:
Заметьте, однако, что в этом тесте нет функции tearDown, что имеет смысл, верно? В конце концов, ничего не записывается в базу данных или в файл.
Но допустим, мы хотим представить тестовый пример, который будет иметь имя файла, содержимое и будет записывать содержимое в файл. В этом случае это будут статические данные, но технически это может быть все, что записано на диск.
1 Настройка теста
Во- первых, мы хотим настроить тест, определив имя файла, содержимое файла и подготовив свойства.
Достаточно легко, верно?
2 Запись и чтение данных
Затем мы хотим записать данные, прочитать данные и подтвердить, что содержимое одинаковое.
На этом этапе, если вы запустите тест (который я еще технически не описал, как это сделать), вы заметите, что файл testFile.txt все еще находится в вашей системе.
3 Использование разрыва
Наконец, нам нужно поработать с методом tearDown, чтобы убедиться, что файл удален после завершения модульного теста. Вот как это может выглядеть, если вы реализовали свой код так, как показано выше.
Обратите внимание, что в методе tearDown я сначала проверяю, существует ли файл file_exists. Это связано с тем, что если вы просто попытаетесь удалить файл, которого нет, вы получите сообщение об ошибке при выполнении тестов, потому что если присутствует tearDown, то он попытается что-то удалить после каждой отдельной тестовой функции. А если файла нет, то и удалять ему нечего, а значит получится проблема.
Поэтому, пытаясь написать защитный код, я считаю, что он отвечает за проверку существования файла, прежде чем пытаться его удалить.
3 Порядок действий
Когда речь заходит о чистом модульном тестировании, обычно вы читаете это с точки зрения разработки через тестирование. Это большая тема сама по себе; тем не менее, стоит упомянуть здесь, если вы решите исследовать его дальше и даже внедрить в свои усилия по разработке.
Общая идея, лежащая в основе этого подхода, часто упоминается как «красный-зеленый-повтор». И я не отрицаю, в этом подходе что-то есть. А именно, это позволяет вам, как разработчику, писать код так, как вы ожидаете, до того, как он будет фактически написан.
Психология, стоящая за этим, такова: если вы знаете, как работает код, вы с большей вероятностью напишете тесты, которые пройдут; тогда как, если вы пишете тесты того, как должен работать код, вы должны писать лучший код.
К сожалению, не всегда мы можем позволить себе такую роскошь. Но это не значит, что мы должны выплеснуть вместе с водой и пресловутого ребенка. Вместо этого я считаю, что вы должны писать тесты, когда можете, а потом писать код; в противном случае пишите свои тесты после кода.
В конечном счете, наличие тестирования в любом случае будет лучше, чем отсутствие тестов вообще.
4 Тестирование с помощью WordPress
Когда дело доходит до модульного тестирования в WordPress, есть несколько вещей, с которыми вы, вероятно, сталкивались. Иногда содержание является неправильным или может даже вводить в заблуждение с точки зрения «модульного тестирования в WordPress».
В данном случае стоит отметить две вещи:
- Тематический модульный тест. Этот конкретный набор контента предназначен для того, чтобы помочь разработчикам тем протестировать все основные и второстепенные случаи для своих тем. Например, нет автоматизированных инструментов, которые вы могли бы использовать, как в том, что мы обсуждали выше.
- Автоматизированное тестирование. WordPress поставляется с собственным набором модульных тестов, поэтому нам не нужно писать тесты для большинства функций WordPress (например, работают ли функции API должным образом). Это позволяет нам сосредоточиться на написании модульных тестов для нашей собственной доменной логики.
- Модульные тесты плагинов. Если вы использовали WP-CLI (или интересуетесь им), то вы, вероятно, читали эту страницу или даже использовали этот инструмент. Это полезно, но также нацелено на определенные аспекты тестирования плагинов WordPress.
Все вышеизложенное является полезной информацией, и я не говорю, что ее следует игнорировать. Вместо этого его следует сочетать с остальной информацией, используемой в этом посте.
Запуск модульных тестов
В следующем посте я расскажу вам обо всем, что вам нужно знать, чтобы настроить файл XML, который будет информировать PHPUnit о том, где находятся тесты и как их запускать.
А пока просмотрите код, приведенный в этом посте, и подготовьтесь к его созданию в следующем посте этой серии.