Лучшие практики для регрессионного тестирования сайтов WordPress?

Привет всем,

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

Для тех, кто не знаком с термином «регрессионное тестирование», Википедия определяет его как:

Регрессионное тестирование - это любой тип тестирования программного обеспечения, целью которого является выявление программных ошибок после внесения изменений в программу (например, исправления ошибок или новые функциональные возможности) путем повторного тестирования программы. Цель регрессионного тестирования состоит в том, чтобы гарантировать, что изменение, такое как исправление ошибки, не привело к появлению новых ошибок.

Википедия рассказывает следующее: именно это я испытываю в проекте прямо сейчас:

Опыт показывает, что поскольку программное обеспечение исправлено, появление новых и / или повторное возникновение старых неисправностей является довольно распространенным явлением. Иногда повторное возникновение происходит, потому что исправление теряется из-за плохой практики контроля версий (или простой человеческой ошибки в контроле версий). Часто решение проблемы будет «хрупким» в том смысле, что оно устраняет проблему в узком случае, когда оно впервые наблюдалось, но не в более общих случаях, которые могут возникнуть в течение срока службы программного обеспечения. Часто исправление проблемы в одной области непреднамеренно приводит к программной ошибке в другой области. Наконец, часто бывает так, что при изменении какой-либо функции в редизайне были сделаны те же ошибки, которые были допущены в первоначальной реализации этой функции.

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

Решение, которое я думаю, состоит в том, чтобы настроить регрессионное тестирование с помощью серии «контрольных примеров», составляющих «набор тестов». В принципе, это не так сложно, когда вы тестируете вывод HTML запросов HTTP GET. Но это становится немного сложнее, когда вам нужно что-то тестировать при входе в систему через консоль администратора и / или для тестирования взаимодействий jQuery.

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

PHPUnit придет в голову, если набор тестов WP не был настолько нарушен, и если WP был спроектирован и написан таким образом, что он действительно мог быть протестирован должным образом. ;-)

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

Среди разноцветных вещей, которые я видел, произошло:

• Незначительное изменение в WP API влияет на функциональность вашего плагина, например, на хук, который вы использовали для получения идентификатора термина, и теперь он получает идентификатор термина таксономии. (Скорее всего, у ваших тестовых терминов одинаковый идентификатор для обоих).

• Незначительное изменение в WP API приводит к тому, что вы получаете WP_Errorобъект вместо ожидаемого ранее значения falseкак неверный ввод.

• Ваш плагин добавляется из папки mu-plugins, что приводит к немного другому потоку кода.

• Ваш плагин работал нормально, пока memcached или другое постоянное хранилище не были включены.

• Ваш плагин работал нормально, пока не был вызван презираемый switch_to_blog ().

• Плагин изменяет хук, на котором он находится, когда вызывается, и неосознанно прерывает его как побочный эффект.

• Плагин (не?) Сознательно портит ваши входные или выходные данные до такой степени, что все выглядит не так, даже если вы не виноваты.

Я мог бы расширять список и продолжать, но это были бы ключевые пункты, которые сломали мои собственные плагины. Эти два предмета, вероятно, можно отследить с помощью модульных тестов. Следующие два также, если вы достаточно терпеливы, но я бы сказал, что WP не должен изменять то, как все работает, когда они происходят. Никакое количество тестирования не будет работать с ошибочной реализацией switch_to_blog (). И последние два безнадежно непроверяемы.

О, и ... даже не начинайте меня с натиска вложений, автоматических черновиков, изменений, пунктов меню и того, что в итоге не сохранится в таблице сообщений.

Удачи... :-)

Вы должны строго рассмотреть Selenium .

Он позволяет вам записывать действия (например, вводить данные в форму, щелкать ссылку), а затем вы можете выполнять утверждения. Он также интегрируется с PHPUnit. Я настоятельно рекомендую проверить двухминутную демонстрацию.

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

Конечно, тесты Codeception WebDriver могут пойти дальше и выполнить функциональные регрессионные тесты. Вы можете заполнять и отправлять формы, нажимать кнопки и ссылки на сайте, запускать любые JS и т. Д. Вы можете использовать в своих тестах реальный браузер, такой как Firefox или Chrome, или вы можете проводить тестирование без помощи PhantomJS . Это означает, что вы даже можете запускать тесты WebDriver для своего плагина в рамках процесса его сборки на Travis CI, если хотите.

Есть даже несколько специфичных для WordPress библиотек, которые помогут вам начать работу:

• WP Browser
• WP Codeception