Каково состояние TDD и / или BDD в PHP?

Есть, по крайней мере, два зрелых, автономных, доступных набора тестов стиля JUnit, называемых PHPUnit и SimpleTest , соответственно.

По мере продвижения MVC Framework, у Symfony есть собственная среда тестирования с именем lime , Code Igniter имеет библиотеку unit_test, а CakePHP полагается на вышеупомянутый SimpleTest.

Я знаю, что Zend Studio встроила поддержку тестов PHPUnit, и у PHPUnit и SimpleTest есть лидеры командной строки, поэтому возможна интеграция в любой рабочий процесс.

Инструменты есть в мире PHP, если разработчик хочет их использовать, а интеллектуальные магазины используют их.

Оговорки – ваш вопрос для ответов на PHP. Есть два сообщества PHP; PHP как платформа для создания программного обеспечения и PHP как способ взаимодействия с веб-сервером, веб-браузером и базой данных для создания подобных приложений в Интернете. Это меньше черно-белая вещь и больше континуум; Среди тех, кто больше тестирует блок разработчиков программного обеспечения и TDD, поддерживается и используется так же, как и на любой другой платформе. Среди «булыжников куча вещей, которые я не понимаю, но все же получаю результаты людей», это неслыханно.

Существует много устаревшего PHP-кода, не относящегося к инфраструктуре / пользовательской структуре, вокруг которого трудно получить полезную тестовую проводку. PHP также легко поддается шаблонам, которые полагаются на существование среды браузера для запуска. У меня нет никаких доказательств, подтверждающих это, кроме моих собственных наблюдений, но многие магазины PHP, которые заботятся о тестировании, в конечном итоге полагаются на приемочные испытания (например, Selenium) в качестве замены фактического тестирования модулей, тестирования и т. Д. развитие.

В вашей конкретной ситуации собеседование с разработчиком вашей группы собирается нанять.

1. Спросите у них, какие рамки тестирования модулей они используют

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

3. Попросите их описать в общих чертах пример реального мира того времени, когда их тесты не удались, и что они сделали для разрешения ситуации

Вас меньше интересует конкретная ситуация, которую они собираются описать, и больше интересуется тем, насколько комфортно они обсуждают свои знания в области тестирования кода в целом.

Всякий раз, когда я TDD проект с инструментами стиля XUnit, мне трудно получить голову в нужном месте. Я считаю, что использование инструментов, предназначенных для Behavior Driven Development или « Specification by example », облегчает мне право TDD – то есть сосредоточиться на дизайне, подвергать намерению и описывать поведение в определенных контекстах . Не тестирование.

Тем не менее, я хотел бы представить в беседу. Из файла readme на сайте проекта.

pecs – крошечная управляемая поведением библиотека разработки для PHP 5.3, a la RSpec или JSpec.

Если вы использовали JSpec или еще лучше, Jasmine-BDD (для JavaScript), стиль описания пешей должен быть действительно знаком. Я считаю этот стиль отличным для спецификаций уровня компонентов. Если вы ищете PHP-инструмент для спецификаций уровня (рассказы или приемочные тесты пользователей), рассмотрите Behat .

Возвращаясь к pecs, вот пример, отбираемый с сайта проекта pecs:

describe("Bowling", function() { it("should score 0 for a gutter game", function() { $bowling = new Bowling(); for ($i=0; $i < 20; $i++) { $bowling->hit(0); } expect($bowling->score)->to_equal(0); }); }); 

Да, это спецификация PHP. Просматривая источник pecs, похоже, что автор может это сделать, используя новую горячность в PHP 5.3+, Lambdas и закрытие. Поэтому я предполагаю, что это означает, что вы не можете использовать pecs в любом проекте на основе PHP <5.3 (только FYI).

Кроме того, pecs не так зреет, как PHPUnit или SimpleTest. Тем не менее, я думаю, что сторонники BDD в сообществе PHP должны поддерживать рост таких инструментов, как pecs, которые поощряют «Specification by example» или BDD без путаницы, вызванной необходимостью использования устаревших инструментов тестирования XUnit.

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

У меня был потрясающий опыт работы с Behat / Mink http://behat.org

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

Обертывание головы вокруг композитора в качестве инструмента построения репо было самым большим камнем преткновения, но мы смогли использовать автономный серверный блок Beach Mink Selenium Webdriver как потрясающий инструмент для проектирования и регрессионного тестирования. Раньше мы использовали наш набор регрессии против нашего приложения CakePHP на сервере Jenkins, но он оказался не настолько «слишком быстрым»

Теперь наш рабочий процесс выглядит следующим образом: Создайте историю в gherkin, улучшите функцию записи истории и запустите любой новый шаг. Defs начните кодирование php-решения для тестирования. Тогда в конце у нас есть работающая функция или исправление ошибок с тестом bdd, охватывающим его

Мы настраиваем виртуальную машину Ubuntu с рабочей настройкой Behat и копируем ее на каждую рабочую станцию. Мы испекли его в нашем процессе. Мы просто сбрасываем тесты на запуск тестов, а затем начинаем кодировать новые вещи.

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

Класс Mink WebAssert дает вам все утверждения, необходимые для проверки поведения. Обычные классы Session / CommonContext отлично подходят для использования css или xpath.

Ранее я использовал Capybara / WebDriver с проектами Java и Rails и обнаружил, что кривая служебных данных / обучения слишком велика по сравнению с Behat.

В дополнение к библиотекам / фреймворкам, которые уже упоминал Алан , вы можете использовать Apache :: Test от mod_perl, который я использую в качестве упряжи. Это позволяет мне очень просто интегрировать тесты в мой процесс выпуска. Жгут использует TAP- выход (Test Anything Protocol), чтобы определить, проходят или не проходят тесты, используя библиотеки, такие как Test :: Simple или Test :: More ( Perl и PHP ).

Из коробки Apache :: Test поддерживает записи тестов как в Perl, так и в PHP. В моих собственных проектах потребовалось немного обмана и много чтения, чтобы действительно заставить его работать, но реализация Test :: More в PHP встроена в проводку. Выполнение всех тестов, написанных как на PHP, так и на Perl, выполняется с помощью одной команды, и любой сбой по пути захватывается Apache :: Test, отмечая, насколько это возможно, что пошло не так.

Огромная часть всего этого заключается в том, что вы даже можете использовать PHPUnit или Simple-Test наряду с двумя предыдущими платформами тестирования. Проводя тесты в каждой соответствующей библиотеке, вы можете использовать реализацию PHP Test :: More (или даже Perl путем тестирования stdout) и отбросить TAP для вашей проводки для интерпретации.

Обязательно прочтите документацию Apache :: Test и руководство mod_perl для запуска Apache :: Test . Кроме того, я нашел статью здесь большую помощь.

В качестве быстрого примера вы можете настроить тест на Perl в очень немногих строках кода, который будет проходить через все страницы вашего сайта (у которых есть ссылки), и проверить все результаты в ответах « 200 OK » и не иметь никакого синтаксического анализа ошибки:

 #!perl use strict; use warnings; use Apache::Test qw(:withtestmore); use Apache::TestRequest; use Test::More; use Test::WWW::Mechanize; use WWW::CheckSite::Validator; use WWW::CheckSite::Spider; plan 'no_plan'; my $config = Apache::Test::config(); my $host = "http://". Apache::TestRequest::hostport($config) || ''; my $s = WWW::CheckSite::Spider->new( uri => $host, ua_class => 'Test::WWW::Mechanize', ); my $m = $s->current_agent; while (my $page = $s->get_page) { is($m->status(), "200", $m->uri() ." retrieved successfully."); $m->content_lacks("Parse Error", $m->uri() ." does not contain syntax errors."); } 

В прошлом проекте я использовал PHPUnit, и это оставило меня желать. PHPUnit + Выполнение тестов в командной строке сделало так, что слишком много времени было потрачено на кодирование тестов, было недостаточно быстро, и действительно казалось, что он ограничивает стиль кода таким образом, который мне не понравился (объекты были легче протестировать, поэтому он, казалось, понравился объектам).

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

В этом последнем проекте ведущий программист взял более функциональный подход к программированию, поскольку мы пересмотрели программное обеспечение. Когда я упомянул о том, что я хотел бы запрограммировать через TDD, он запустил собственное решение за день или меньше, что я считаю эффективным для меня как PHPUnit. Кроме того, он действительно открыл мне глаза на вопрос об объектно-ориентированном и функциональном программировании.

Первый проект, начатый с нуля, на первом этаже, объектно-ориентированное кодирование, большая платформа тестирования модулей, он стал монолитным и быстро увяз. Второй проект, хорошо зарекомендовавшее себя программное обеспечение CMS с 5-летней историей и старым кодом, но парадигма функционального программирования и простая структура тестирования (мы фактически часто использовали php assert) заставили его упроститься, а не увеличиваться по сложности.

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

Я только что нашел этот вопрос, и, пока я все еще на стадии исследования, выясняю, что происходит. Я только что открыл что-то для Ruby on Rails под названием «Огурец» http://cukes.info/

Это, по сути, «история развития» для Ruby и, вполне возможно, золотой стандарт в области функционального тестирования, по крайней мере, насколько я видел в своих путешествиях. (Я публиковал это публично, поэтому эксперты могут исправить меня, если я ошибаюсь)

В качестве примера языка в Cucumber у вас есть то, что очень близко напоминает SQL. НО, похоже, еще более удобочитаемо. На первой странице cukes их язык выглядит так:

  Scenario: Add two numbers Given I have entered 50 in the calculator And I have entered 70 in the calculator When I press add Then the result should be 120 on the screen 

Вышеприведенное будет компилироваться и выполняться как тест.

Теперь это все преамбула, чтобы ответить на ваш вопрос о PHP – BDD & TDD.

Повторяя приведенные выше комментарии, PHPUnit позволит тестировать модули и согласно этому сообщению в блоге: http://sebastian-bergmann.de/archives/738-Support-for-BDD-and-Stories-in-PHPUnit-3.3.html также поддерживает тестирование BDD «стиль истории».

Чтобы расширить приведенный выше ответ в отношении упомянутого выше «SIMPLETEST», система ST имеет встроенный класс объектов браузера для автоматизации браузера, а PHPUnit имеет расширение для автоматизации браузера SELENIUM http://seleniumhq.com (преимущество Selenium vs. SimpleTest – это то, что Selinium будет запускать любой на странице javascript, в то время как SimpleTest не будет).

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

• Алекс.

Майкл Бут сравнивает возможности тестирования BDD на обоих языках:

http://mechanicalrobotfish.com/posts/117-ruby-vs-php-bdd-beauty-contest-no-contest

приходит к выводу, что на данный момент инструменты и культура PHP BDD недостаточно развиты.

Конечно, ничто не сравнимо с тем, что доступно программисту Ruby, либо с точки зрения знаний (книги, видео, статьи, сообщения в блогах), либо инструменты (Rspec, Shoulda, Factory Girl, Mocha, Cucumber).

Возможно, вы захотите проверить PHPStorm . Мне нравятся тестовые ролики, которые используют PHPUnit из среды IDE.

Теперь я разрабатываю рамки «Spectrum» для теста BDD: https://github.com/m-haritonov/spectrum