В последних двух статьях мы подробно рассмотрели теорию модульного тестирования и то, как она может помочь нам в наших усилиях по разработке на WordPress. Мы определили модульное тестирование и изучили различные способы, которые могут помочь нам в наших проектах.
Но у нас еще есть что рассказать.
В этой заключительной статье мы рассмотрим, почему мы должны вообще заниматься модульным тестированием, и суммируем преимущества и недостатки этого. Далее мы рассмотрим, как мы можем модернизировать тестирование в наших существующих проектах. И в заключение мы подведем итоги списка ресурсов, которые доступны специально для нас, разработчиков WordPress, которые помогут начать модульное тестирование наших тем.
Почему мы юнит тестирование: все о качестве
Основная тема всей этой серии была о том, почему мы должны беспокоиться о модульном тестировании, но если это не было кратко заявлено, вот почему:
Модульное тестирование помогает нам быстрее выявлять проблемы, обеспечивает разработчиков уровнем самодокументируемого кода и обеспечивает более высокий уровень качества программного обеспечения.
Конечно, это предполагает, что мы будем придерживаться хороших методов юнит-тестирования. Конечно, это было подробно описано в предыдущей статье, но это стоит повторить.
Важно отметить — особенно если вы пытаетесь применить это в более корпоративной среде или в контексте более крупного бизнеса — это то, что модульное тестирование — это не просто то, что разработчики делают для себя. Качество двустороннее — оно приносит пользу клиенту и приносит пользу бизнесу.
Предоставляя заказчику более высокий уровень качества, т. Е. Более тщательно протестированное программное обеспечение, у него должно быть меньше ошибок. Поскольку ошибки приводят к тому, что разработчикам приходится тратить время на решение, а не на работу над новыми проектами или новыми функциями существующих продуктов, это в конечном итоге может сэкономить деньги.
Обеспечивая более высокий уровень качества для бизнеса, разработчики становятся более уверенными в своих усилиях, поскольку они могут выполнять набор тестов каждый раз, когда вносятся изменения, зная, как их работа повлияла на все приложение. Если тест не пройден, они могут разрешить его, прежде чем развернуть в рабочей среде.
Модульное тестирование касается качества, и оно затрагивает не только тех, кто пишет код, но и бизнес, который его отправляет, и клиентов, которые его используют.
Преимущества и недостатки
Правда в том, что мы уже рассмотрели преимущества модульного тестирования. Для полноты давайте суммируем их здесь (хотя вы всегда можете рассмотреть их подробно !). Модульное тестирование …
- Помогает разработчикам рано находить проблемы и может экономить время по мере роста приложения и внедрения новых функций.
- Обеспечивает уровень документации в коде, чтобы нынешние и будущие разработчики могли понять, как должен работать код
- Управляет архитектурой, чтобы приложение можно было тестировать на протяжении всего жизненного цикла.
- Улучшает язык кода, предоставляя более читаемые функции и поток управления
Все звучит замечательно, правда? И да, это основано на том, что разработчики считают себя ответственными перед высокими стандартами и практиками, когда дело доходит до фактического внедрения этого в повседневную работу, но модульное тестирование не лишено недостатков.
Время — деньги, а ты проводишь время
Об этом говорилось на протяжении всей серии: модульное тестирование требует значительных временных затрат. По общему признанию, если вы начинаете новый проект, затраты времени намного меньше, чем если вы встраиваете это в существующее приложение, но вам все равно придется писать больше кода, чем без тестирования.
Поскольку вы пишете больше кода, вы тратите больше времени — опять же, на передний план проекта. Преимущества модульного тестирования часто приходят не позже, но если проект имеет конкретную целевую дату для выпуска, и этот выпуск включает в себя определенное количество функций, вы вряд ли поместите все модульные тесты и функции в релиз.
Если вы хотите избежать небольших наборов функций при выпуске или с задержкой намеченных дат, вам нужно вовремя построить модульное тестирование.
Сложность убивает и другие клики
Вы слышали их все: сложность убивает, делайте это просто глупо, меньше значит больше и так далее.
Честно говоря, все они верны и имеют свое место в разработке, но дело в том, что модульное тестирование — это дополнительный код, а дополнительный код всегда вносит больше сложности. Таким образом, мы должны убедиться, что у нас есть правильный способ управления и организации всех наших модульных тестов.
Возможно, это файловая организация, или интервал имен, или соглашения об именах, или версионные тесты, или все вышеперечисленное. Что бы вы ни делали, юнит-тесты не должны рассматриваться как второсортные граждане в мире программного обеспечения — они должны в максимально возможной степени подчиняться тем же принципам проектирования, что и другие классы или функции.
Обратная сторона дизайна
Да, в прошлой статье мы говорили, что модульное тестирование может помочь в разработке дизайна приложения, а также может помочь в разработке дизайна, который делает все приложение более тестируемым. Это все еще верно, но это происходит за счет: иногда наиболее тестируемый дизайн не самый ясный.
Под этим я подразумеваю, что, поскольку набор функций — или даже класс — полностью тестируется модулем, сплоченность может быть скомпрометирована, потому что мы жертвуем доступом к определенным функциям для проверки их обработки данных. Конечно, это не жесткое и быстрое правило, и для некоторых это может даже не быть проблемой, но вы должны решить, в чем вы будете догматичны: это идеально спроектированный набор классов и / или функций или непрерывная система тестов и функций, которые работают вместе?
В конечном счете, я считаю, что все сводится к тому, как вы рассматриваете тесты как большую часть целого. Если они являются частью дизайна вашего приложения, то дизайн может не пострадать. Но если вы рассматриваете тесты как запоздалую мысль, то дизайн основного приложения может быть слегка скомпрометирован.
Непрерывная настройка
Как говорится, программное обеспечение никогда не выполняется, и поскольку модульное тестирование является частью программного обеспечения, оно никогда не выполняется.
Поскольку приложение всегда будет развиваться — будь то устранение ошибок, введение новых функций (или даже удаление), связанные с ними тесты также необходимо будет добавить или обновить. И это всегда возвращается во времени.
Кроме того, если вы работаете в команде разработчиков, отсутствие обновлений тестов может негативно повлиять на команду, так как результаты, представленные в отчетах о тестах, могут быть ложными или ложными отрицательными. После написания тестов обязательно, чтобы они были обновлены; в противном случае они могут привести к очень плохому продукту.
Включение модульного тестирования в ваш рабочий процесс
Модульное тестирование гораздо проще продать, когда вы начинаете с проектом, но если вы хотите перестроить его в существующее приложение (или тему или плагин, в нашем случае), это займет немного времени и усилия.
И хотя нет никакой серебряной пули для того, как вы можете отлично выполнить это, есть несколько хороших способов начать применять эту практику в своей повседневной работе:
- Убедитесь, что ваш проект находится под контролем исходного кода — это должно быть само собой разумеющимся, но если это не так, начните как можно скорее. « Как и почему » выходят за рамки данной статьи, но очень важно, чтобы ваша работа находилась под контролем исходного кода, особенно после введения тестов.
- Знакомьтесь с модульными тестами WordPress. Начните настройку с помощью модульных тестов WordPress (инструкции здесь ). Я рекомендую хранить их в подкаталоге вашего проекта, чтобы упростить организацию тестов. Убедитесь, что они взяли на себя обязательство контроля над источниками.
- Начните добавлять тесты — каждый раз, когда вы работаете над функцией или вводите новую функцию, добавляйте соответствующий модульный тест. Если уже существующая функция не поддается тестированию, потратьте время, чтобы убедиться, что это так. Это тяжелая битва, но она окупится.
- Помните об успехах и неудачах. Помните, что при написании тестов вы также должны вводить тесты для случаев успеха и тесты для случаев отказа.
Если вы выполните описанные выше шаги, вы в конечном итоге получите значительное количество кода. Да, это занимает время, и да, вам, вероятно, придется переделывать большую часть кода, но эти же временные вложения принесут дивиденды в будущем вашего продукта.
Доступные ресурсы
Вот краткое изложение ресурсов, которые могут способствовать успешному тестированию ваших проектов на WordPress:
- Руководство для начинающих по модульному тестированию — серия статей, которые я написал, в которых рассказывается о модульном тестировании и о том, как тестировать плагины и темы.
- PHPUnit — платформа, на которой основаны тесты WordPress.
- PHPUnit Documentation — Руководство по PHPUnit. Это полезно, когда вы ищете доступные методы для написания утверждений в вашем коде.
- Hello Reader — простой плагин, который я написал, чтобы продемонстрировать, как выполнять модульное тестирование плагинов.
- Тесты WordPress — официальные тесты WordPress и инфраструктура тестирования, доступные для проверки через Subversion.
- Основная тема — простая тема WordPress, используемая для демонстрации того, как создавать модульные темы тестирования.
Между первой серией статей и этой серией статей была заложена прочная основа, на которой вы можете продолжать строить свои методы модульного тестирования.