Какое состояние TDD и/или BDD в PHP?
Насколько широко распространенный, поддерживаемый, разработанный тестируется в мире PHP? Наравне с Java? Там с Ruby/Rails? Я Googled и обнаружил, что существуют рамки тестирования, но мне интересно, широко используются они.
У основных PHP IDE есть встроенные тестовые ролики, как это делают инструменты Java Eclipse или инструменты Ruby/Rails от NetBeans? Является ли тестирование встроенным в фреймворк PHP MVC как с Rails?
Я спрашиваю, потому что группа, в которой я работаю, хочет нанять кого-то, чтобы разработать для них приложение PHP. Меня беспокоит качество и обслуживание, поскольку меня могут призвать поддержать эту вещь.
Ответы
Ответ 1
Существует, по крайней мере, два зрелых автономных набора тестов стиля 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) в качестве замены фактического тестирования модулей, тестирования и т.д.. разработки.
В вашей конкретной ситуации собеседование с разработчиком вашей группы собирается нанять.
-
Спросите у них, какой модуль тестирования модулей они используют.
-
Попросите их описать в общих чертах пример реального мира того времени, когда они разработали новую функцию и ее поддерживающие тесты
-
Попросите их описать в общих чертах пример реального мира того времени, когда их тесты потерпели неудачу и что они сделали, чтобы решить ситуацию.
Вы менее заинтересованы в конкретной ситуации, которую они собираются описать, и больше заинтересованы в том, насколько комфортно они обсуждают свои знания по тестированию кода в целом.
Ответ 2
Всякий раз, когда я TDD проект с инструментами стиля XUnit, мне трудно получить голову в нужном месте. Я нахожу, что использование инструментов, предназначенных для Behavior Driven Development или "" Спецификация на примере "облегчает мне do TDD right - то есть сосредоточиться на дизайне, разоблачении намерения и описать поведение в конкретных контекстах. Не.
Тем не менее, я хотел бы ввести pecs в разговор. Из файла readme на сайте проекта.
pecs - крошечная управляемая поведением библиотека разработки для PHP 5.3, a la RSpec или JSpec.
Если вы использовали JSpec или еще лучше, Jasmine-BDD (для JavaScript), стиль pecs описания поведения должен быть действительно знаком. Я считаю этот стиль отличным для спецификаций уровня компонентов. Если вы ищете 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, для разработки спецификаций для программного обеспечения.
Ответ 3
У меня был потрясающий опыт работы с Behat/Mink http://behat.org
Я согласен с другими php в качестве платформы тестирования модулей, это не забава или опыт. BDD - лучший способ пойти, если вы используете фрейм фреймворка
Обертывание моей головы вокруг композитора в качестве инструмента построения репо было самым большим камнем преткновения, но мы смогли использовать автономный серверный блок Beach Mink Selenium Webdriver как потрясающий инструмент для проектирования и регрессионного тестирования. Раньше мы использовали наш набор регрессии против нашего приложения CakePHP на сервере Jenkins, но он оказался не настолько "слишком быстрым".
Теперь наш рабочий процесс выглядит следующим образом:
Создать историю в огурцах
уточнить историю
написать функцию и заглушить любой новый шаг defs
начать программирование php для тестирования
Затем в конце у нас есть работающая функция или исправление ошибок с тестом bdd, охватывающим его
Мы настроили виртуальную машину Ubuntu с рабочей настройкой Behat и скопировали ее на каждую рабочую станцию. Мы испекли его в нашем процессе. Мы просто сбрасываем тесты тестов изменений, а затем начинаем кодировать новые вещи.
Мы написали оболочку script, чтобы автоматически запускать дампы mysql и загружать их перед каждой функцией, которая сделала рефакторинг код легким.
Класс Mink WebAssert дает вам все утверждения, необходимые для проверки поведения
Обычные сессии/классы CommonContext отлично подходят для использования css или xpath.
Ранее я использовал Capybara/WebDriver с проектами Java и Rails и обнаружил, что кривая служебных данных/обучения установки слишком высока по сравнению с Behat.
Ответ 4
В дополнение к библиотекам/фреймворкам, которые Алан уже упоминал, вы можете использовать mod_perl Apache:: Test, который я использую в качестве упряжи. Это позволяет мне очень просто интегрировать тесты в мой процесс выпуска. В жгуте используется 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
" и "не использовать", t есть ошибки анализа:
#!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.");
}
Ответ 5
В прошлом проекте я использовал PHPUnit, и это оставило меня желающим.
PHPUnit + Командная строка, выполняющая тесты,
сделал так, что слишком много времени было потрачено на кодирование тестов, не было достаточно быстрым и, по-видимому, сдерживало стиль кода таким образом, что мне не нравилось (объекты легче тестировать, так что это казалось любопытным для объектов).
Selenium был решением, о котором мы говорили, но так и не добрались до игры, и я думаю, что мы действительно выиграли бы от такого уровня тестирования на уровне выпуска.
В этом последнем проекте ведущий программист использует более функциональный подход к программированию, поскольку мы пересмотрели программное обеспечение. Когда я упомянул о том, что я хотел бы запрограммировать через TDD, он запустил собственное решение за день или меньше, что я считаю эффективным для меня как PHPUnit. Кроме того, он действительно открыл мне глаза на вопрос объектно-ориентированного и функционального программирования.
Первый проект, начатый с нуля, на первом этаже, объектно-ориентированное кодирование, большая платформа тестирования модулей, он стал монолитным и быстро увяз. Второй проект, хорошо зарекомендовавшее себя CMS-программное обеспечение с 5-летней историей и старым кодом, но парадигма функционального программирования и простая структура тестирования (мы фактически часто использовали php assert), упростили ее, а не выросли по сложности.
Второй проект тоже не дошел до внедрения Selenium (и я все еще думаю, что это было бы полезно), но подход к функциональному программированию упростил работу с тестированием в коде.
Ответ 6
Я только что нашел этот вопрос и, пока я все еще на стадии исследования, выясняю, что происходит. Я только что открыл что-то для 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 не будет).
Надеюсь, вы найдете эту информацию полезной, так как это результат нескольких месяцев личных исследований и практических испытаний и ошибок с вышеупомянутыми технологиями. Если есть эксперты, которые могут уточнить и улучшить мое понимание вышеизложенного, я приветствую отзывы.
Ответ 7
Майкл Бут сравнивает функции тестирования BDD на обоих языках:
http://mechanicalrobotfish.com/posts/117-ruby-vs-php-bdd-beauty-contest-no-contest
делает вывод о том, что на данный момент инструменты и культура PHP BDD недостаточно развиты.
Конечно, ничто не сравнимо с тем, что доступно программисту Ruby, либо с точки зрения знаний (книги, видео, статьи, сообщения в блогах), либо инструменты (Rspec, Shoulda, Factory Girl, Mocha, Cucumber).
Ответ 8
Теперь я разрабатываю рамки "Spectrum" для теста BDD: https://github.com/m-haritonov/spectrum
Ответ 9
Возможно, вы захотите проверить PHPStorm. Мне нравятся тестовые ролики, которые используют PHPUnit из среды IDE.