Каково состояние TDD и/или BDD в PHP?[закрыто]
https://stackoverflow.com/questions/530712
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Насколько широко распространено, поддерживается и развито тестирование в мире PHP?Наравне с Явой?Там, где Ruby/Rails?Я погуглил и обнаружил, что среды тестирования существуют, но мне интересно, широко ли они используются.
Имеют ли основные PHP IDE встроенные средства запуска тестов, как это делают инструменты Java Eclipse или инструменты Ruby/Rails NetBeans?Встроено ли тестирование в PHP-фреймворки MVC, как в Rails?
Я спрашиваю, потому что группа, в которой я работаю, хочет нанять кого-нибудь для разработки для них приложения PHP.Меня беспокоит качество и обслуживание, так как меня могут попросить поддержать эту вещь.
Решение
Доступны как минимум два зрелых, автономных набора тестов в стиле JUnit, названных PHPUnit и Простой тест, соответственно.
Что касается MVC Frameworks, у Symfony есть собственная среда тестирования под названием лайм, Code Igniter имеет модульный тест библиотека и ТортPHP опирается на вышеупомянутый SimpleTest.
Я знаю, что Zend Studio имеет встроенную поддержку тестов PHPUnit, а PHPUnit и SimpleTest имеют средства запуска командной строки, поэтому возможна интеграция в любой рабочий процесс.
В мире PHP есть инструменты, если разработчик хочет ими воспользоваться, и умные магазины ими пользуются.
Предостережения — это ваш стандарт для жалоб на PHP.Существует два сообщества PHP;PHP как платформа для создания программного обеспечения и PHP как способ взаимодействия с веб-сервером, веб-браузером и базой данных для создания приложений, подобных приложениям, в сети.Это не столько черно-белое явление, сколько континуум;Среди прочего, модульное тестирование со стороны разработчиков программного обеспечения и TDD поддерживаются и используются так же, как и на любой другой платформе.Среди людей, которые «собирают кучу вещей, которых я не понимаю, но все равно получают результаты», это неслыханно.
Существует много устаревшего PHP-кода, не относящегося к фреймворку или нестандартного фреймворка, вокруг которого сложно найти полезный тестовый набор.PHP также легко поддается шаблонам, запуск которых зависит от наличия среды браузера.У меня нет никаких доказательств, подтверждающих это, кроме моих собственных наблюдений, но многие магазины PHP, которые заботятся о тестировании, в конечном итоге полагаются на приемочное тестирование (т.Selenium) вместо фактического модульного тестирования, «сначала тестирование» и т. д.разработка.
В вашей конкретной ситуации проведите собеседование с разработчиком, которого собирается нанять ваша группа.
Спросите их, какую среду модульного тестирования они используют.
Попросите их описать в общих чертах реальный пример того, как они разработали новую функцию и ее подтверждающие тесты.
Попросите их описать в общих чертах реальный пример случая, когда их тесты не увенчались успехом, и что они сделали, чтобы разрешить ситуацию.
Вас меньше интересует конкретная ситуация, которую они собираются описать, и больше интересует то, насколько комфортно они обсуждают свои знания о тестировании кода в целом.
Другие советы
Всякий раз, когда я тестирую проект с помощью инструментов стиля XUnit, мне трудно направить голову в нужное место.Я считаю, что использование инструментов, предназначенных для разработки, основанной на поведении, или «Спецификация на примере", мне легче делай TDD правильно -- т.е.сосредоточиться на дизайне, раскрывая намерения и описание поведения в конкретных контекстах. Нет тестирование.
Тем не менее, я хотел бы представить грудные мышцы в разговор.Из readme на сайте проекта.
pecs — это крошечная библиотека разработки, управляемая поведением, для PHP 5.3, в стиле RSpec или JSpec.
Если вы использовали JSpec или еще лучше, Жасмин-BDD (для JavaScript) стиль описания поведения pecs должен быть очень знаком.Я считаю, что этот стиль отлично подходит для спецификаций на уровне компонентов.Если вы ищете инструмент PHP для спецификаций уровня функций (истории или пользовательские приемочные тесты), рассмотрите возможность Бехат.
Возвращаясь к 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+, лямбды и замыкания.Я предполагаю, что это означает, что вы не можете использовать pecs ни в одном проекте, основанном на PHP < 5.3 (просто к вашему сведению).
Кроме того, pecs не так развит, как PHPUnit или SimpleTest.Тем не менее, я думаю, что сторонники BDD в сообществе PHP должны поддерживать развитие таких инструментов, как pecs, которые поощряют «спецификацию на примере» или BDD, без путаницы, вызванной необходимостью использования устаревших инструментов тестирования XUnit.
Сейчас я больше работаю с Python, чем с PHP.Однако в следующий раз, когда я возьму PHP-проект, я буду очень рад, если у меня будет зрелый, поддерживаемый сообществом инструмент, такой как pecs, для создания спецификаций для программного обеспечения.
У меня был потрясающий опыт работы с Behat/Mink. http://behat.org
Я согласен с другими, что PHP, поскольку платформа модульного тестирования — это не развлечение и не опыт. BDD — лучший способ, если вы используете какую-либо платформу PHP.
Самым большим камнем преткновения для меня было рассмотрение композитора как инструмента сборки репозитория, но мы смогли использовать автономный серверный jar-файл Behat Mink Selenium Webdriver в качестве потрясающего инструмента проектирования и регрессионного тестирования.Раньше мы запускали наш пакет регрессии для нашего приложения CakePHP на сервере Jenkins, но он оказался недостаточно «быстрым»
Теперь наш рабочий процесс выглядит следующим образом:Создать историю в Геркине Уточнить функцию записи истории и загрязнить любой новый шаг def Def Begining Coding PHP -решение
Мы настроили виртуальную машину Ubuntu с работающей настройкой Behat и скопировали ее на каждую рабочую станцию.Мы включили это в наш процесс.Мы просто вносим изменения, запускаем тесты, а затем начинаем кодировать что-то новое.
Мы написали сценарий оболочки для автоматического запуска дампов MySQL и их загрузки перед каждой функцией, что упростило рефакторинг кода.
Класс Mink Webassert дает вам все утверждения, необходимые для проверки поведения, регулярные классы сеанса / CommonContext отлично подходят для использования CSS или XPath.
Раньше я использовал Capybara/WebDriver с проектами Java и Rails и обнаружил, что затраты на установку/кривую обучения слишком высоки по сравнению с Behat.
В дополнение к библиотекам/фреймворкам, которые Алан как уже упоминалось, вы можете использовать Apache::Test mod_perl, который я использую в качестве средства.Это позволяет мне очень просто интегрировать тесты в процесс выпуска.В жгуте используются КРАН вывод (протокол Test Anything), чтобы определить, пройдены или нет тесты, используя такие библиотеки, как Тест::Простой или Тест::Больше (Перл и PHP).
«Из коробки» Apache::Test поддерживает написание тестов как на Perl, так и на PHP.В моих собственных проектах это заняло немного немного хитрости и много чтения, чтобы действительно заставить его работать, но реализация Тест::Больше в PHP встроен в обвязку.Запуск всех тестов, написанных как на PHP, так и на Perl, выполняется с помощью одной команды, и любой сбой на этом пути фиксируется Apache::Test, отмечая, насколько это возможно, что пошло не так.
Самое замечательное во всем этом то, что вы даже можете использовать PHPUnit или Simple-Test вместе с двумя предыдущими средами тестирования.Запуская тесты в каждой соответствующей библиотеке, вы можете использовать PHP-реализацию Test::More (или даже Perl, проверяя стандартный вывод) и возвращать TAP для интерпретации.
Обязательно прочтите Апач::Тест документация и 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, Musta, Factory Girl, Mocha, Cucumber).
Возможно, вы захотите проверить PHPStorm.Мне нравятся средства запуска тестов, использующие PHPUnit из IDE.
Сейчас я разрабатываю фреймворк «Спектр» для BDD-теста: https://github.com/m-haritonov/spectrum
