Мы занимались модульным тестированием для разработки на WordPress. Используя практические примеры, мы рассмотрели, как выглядит модульное тестирование как для плагинов, так и для тем ; тем не менее, мы на самом деле не говорили о теории модульного тестирования.
То есть мы не рассматривали на высоком уровне, что это такое, почему это полезно, и как мы можем включить это в наш рабочий процесс. В следующей серии статей мы опишем модульное тестирование, расскажем о его основных преимуществах, о том, почему мы должны заниматься этим, и о некоторых ресурсах, которые мы можем использовать в нашей работе.
Хотя для этого конкретного учебника нет кода, над которым нужно работать, он должен обеспечить прочную основу, на которой основано практическое применение предыдущих статей.
О модульном тестировании тем и плагинов
Перед тем, как углубиться в статью, я думаю, что важно рассмотреть причины, по которым вообще стоит беспокоиться о тестировании тем и плагинов.
До недавнего времени WordPress рассматривался главным образом как платформа для ведения блогов и как система управления контентом. Он отлично справляется с обеими задачами , но по мере того, как разработчики открывают для себя его богатый API, становится все более популярным создание приложений определенных типов с использованием WordPress в качестве базовой платформы.
Кроме того, темы — это больше, чем скины для веб-сайта — это больше, чем таблица стилей и несколько файлов шаблонов для отображения данных. Фактически, сейчас, возможно, больше, чем когда-либо, целые команды посвящают время (и даже зарабатывают на жизнь) созданию тем для WordPress. Так что не позволяйте слову «тема» вводить вас в заблуждение — темы похожи на приложения для WordPress. Они добавляют функциональность, предварительно обрабатывают и обрабатывают данные, и часто вводят в WordPress значительную функциональность, выходящую далеко за рамки простого обновления вашего сайта.
Наконец, плагины почти больше похожи на приложения, чем на темы. Рассмотрим это так: плагины расширяют ядро WordPress, и они часто работают независимо от тем. Вместо этого они добавляют совершенно новые функции в ядро WordPress, из которых могут извлечь выгоду все темы.
Я говорю все это, чтобы дать некоторое представление о том, почему модульное тестирование — как мы собираемся обнаружить — может окупиться много раз, учитывая, что оно используется в контексте более сложных тем и плагинов.
Что такое модульное тестирование?
Мы кратко коснулись этого в первой статье серии. Я не хочу давать полную перефразировку того, что уже было написано, поэтому я суммирую пункты здесь:
- Это практика, чтобы функциональные блоки кода работали как положено
- Это дает нам возможность находить ошибки в нашем коде перед выпуском его в дикую природу.
- Код становится более устойчивым к изменениям, потому что он постоянно тестируется
Но это только царапина на поверхности.
Определение единиц
Чтобы по-настоящему понять единицы вашей темы или плагина, вы должны подумать о том, что составляет тему. Как правило, это сочетание:
- Таблицы стилей, которые дают теме ее представление
- JavaScript (обычно на основе jQuery), который управляет поведением на стороне клиента
- PHP, который обрабатывает обработку на стороне сервера
Хотя для JavaScript существуют фреймворки для модульного тестирования , мы сосредоточимся на PHP-аспекте разработки WordPress. В конце концов, если бы не функциональность на стороне сервера, в WordPress было бы очень мало уникальных функций.
С учетом сказанного существует несколько способов определения единицы, но я бы поспорил, что большинство людей определяют единицу как функцию. По большей части это правильно, но это не значит, что наши функции являются наиболее оптимальными единицами для тестирования. Например, функции часто состоят из нескольких блоков — возможно, циклов, возможно, условных или, возможно, вызовов других функций.
Как бы то ни было, в методах часто содержатся более мелкие единицы функциональности.
Так правильно ли говорить, что модульное тестирование включает в себя тестирование каждой функции, составляющей тему? На самом деле, нет. Поскольку за выполнение конкретной задачи отвечает один блок кода или, в некоторых случаях, один оператор, они будут составлять истинные единицы кода.
И если мы должны писать модульные тесты, как мы пишем тесты для модулей, существующих в наших функциях?
Больше тестов, больше методов
Напомним, что ранее в серии я сказал:
- Сначала напишите свои тесты, а затем запустите их (конечно, они не пройдут)
- Напишите код, чтобы попытаться пройти тесты
- Запустите тесты. Если они проходят, ты хороший; в противном случае продолжайте работу над функцией
Вот где происходит одно из самых больших сдвигов в написании тестируемого кода: вы разбиваете функциональные блоки на наименьшие возможные атомарные части. Конечно, это часто приводит к большому количеству очень маленьких функций, но разве это плохо?
При этом каждая функция действительно имеет одну цель. И если предположить, что ваша функция делает что-то одно, существует только так много способов назвать функцию, что в конечном итоге может привести к гораздо более читаемому коду.
Конечно, есть компромисс, так как вы, возможно, вводите еще несколько строк кода при написании этих дополнительных функций, но когда вы работаете над продуктом с командой других людей, которые будут использоваться тысячами клиентов, Вы должны спросить себя, стоит ли дополнительный код того качества, которое вы можете получить при правильном тестировании своей работы. Если все сделано правильно, ваша команда сможет легче следовать логике кода, и продукт будет иметь такой уровень качества, которого зачастую трудно достичь без написания модульных тестов.
Единицы и Люксы
В модульных тестах следует признать, что они не зависят друг от друга. Один модульный тест должен проверить одну и только одну вещь. Кроме того, это означает, что модульный тест должен действительно включать только одно утверждение (но есть исключения, которые демонстрируются здесь ).
Помните: целью модульного теста является оценка качества отдельной единицы кода. Некоторые модули будут принимать аргументы, некоторые — нет, некоторые будут возвращать значения, другие — нет. В любом случае, ваш модульный тест должен оценить все случаи. Одна единица кода редко будет иметь один тест.
Вместо этого я бы сказал, что хорошее эмпирическое правило заключается в том, что количество тестов, связанных с единицей кода, масштабируется экспоненциально в зависимости от количества входов, которые он принимает.
Например:
- Если ваш блок не принимает аргументов, скорее всего, будет один тест
- Если ваше устройство принимает один аргумент, вероятно, будет два теста — один для ожидаемого аргумента и один для неожиданного
- Если ваше устройство принимает два аргумента, вероятно, будет четыре теста — по одному для каждой комбинации аргументов: ожидаемый, ожидаемый; ожидаемый, неожиданный; неожиданный, ожидаемый; и неожиданно, неожиданно
Есть смысл? Ключевым моментом здесь является то, что у вас будет значительно больше тестов, чем единиц; нет соотношения 1: 1.
Наконец, при выполнении модульного тестирования вы часто будете видеть слово «набор тестов» или «набор», используемое при обсуждении тестов. Это может варьироваться в зависимости от контекста, в котором проводится тестирование; однако при работе с WordPress это обычно относится к набору модульных тестов.
Допустим, у вас есть файл, который отвечает за тестирование всей функциональности, связанной с написанием и публикацией поста — этот файл будет набором тестов для постов. Достаточно просто, правда? Важно понимать эту терминологию, если вы столкнетесь с этим в дальнейшем чтении, поскольку она может немного отличаться, если вы работаете, например, в Rails или .NET.
Платформа Агностик
Наконец, модульное тестирование не является новой методологией и не строго ограничено PHP. На самом деле, модульное тестирование (или разработка на основе тестирования в целом) существует уже более десяти лет.
Вы можете найти рамки модульного тестирования для Java , .NET , Rails , PHPUnit (очевидно) и так далее.
Но его принятие было неоднозначным — некоторые люди живут и умирают этим, другие ненавидят его, и есть некоторые из нас, которые хотят начать это делать, но должны сбалансировать практическое применение приведения его в существующий проект и понимания количество рефакторинга это может потребовать.
Следующий
Что касается теории, мы только начинаем.
В следующей статье мы рассмотрим основные преимущества модульного тестирования и то, как он может окупиться в нашей разработке на WordPress. Мы также рассмотрим преимущества модульного тестирования для архитектуры, дизайна и документации.
Конечно, модульное тестирование не лишено недостатков, поэтому мы также рассмотрим их.