Комментарии 42
В Ruby on Rails для тестирования страниц традиционно используется связка cucumer+webrat+nokogiri. В мире PHP все оказалось несколько сложнее…
Ну вообще-то, Webrat уже доживает свое и на смену ему давненько пришел Capybara.
Написанием альтернативы Capybara для php 5.3 я сейчас и занимаюсь полным ходом ;-)
Ты уже мой самый любимый разработчик) Повторно лучи добра)
Собственно, «done»: Mink.
{grammar_nazi_on} features, а не fetures, а не (поиском найдете)
{grammar_nazi_off}
А вообще интересная тема, спасибо.
{grammar_nazi_off}
А вообще интересная тема, спасибо.
Раз уж вы освоили Ruby и добрались до Cucumber, зачем вам на работе PHP?
Ruby, к превеликому сожалению, крайне непопулярен у нас в городе. Сейчас стараюсь целиком уйти в рельсо-фриланс. Небезуспешно, тьфу-тьфу…
Какая разница на чем писать, если ты делаешь это качественно?
Я вас уверяю, нет никакой разницы на чем писать говно и никакой разницы на чем писать «конфетку».
Да, у PHP есть недостатки и их море, но у Ruby и рельс нет ничего такого, что бы нельзя было написать или использовать в PHP.
Проблема не в языках и фреймворках, а в нашем коде и том, как мы его пишем!
Я вас уверяю, нет никакой разницы на чем писать говно и никакой разницы на чем писать «конфетку».
Да, у PHP есть недостатки и их море, но у Ruby и рельс нет ничего такого, что бы нельзя было написать или использовать в PHP.
Проблема не в языках и фреймворках, а в нашем коде и том, как мы его пишем!
Проблема в языках тоже. ЯП должен поощрять и подталкивать к написанию хорошего кода.
Вообще, на тему «можно написать и использовать». А что было придумано в PHP за все его время существования? Ничего. Все (абсолютно все?) идеи копируются из других языков. Мы только в 2010 увидим «правильные» веб фреймворки, ORM, BDD-фреймворки. Возможно, потому, что это стало возможно только с появлением PHP 5. Сейчас многие языки разиваются в сторону распараллеливания и тредов. Можно ли это в пхп написать и использовать? Нет, никто не будет писать. Неизвестно даже будет ли UTF-8 и PHP 5.6 вообще…
Ну а Behat клевый.
Вообще, на тему «можно написать и использовать». А что было придумано в PHP за все его время существования? Ничего. Все (абсолютно все?) идеи копируются из других языков. Мы только в 2010 увидим «правильные» веб фреймворки, ORM, BDD-фреймворки. Возможно, потому, что это стало возможно только с появлением PHP 5. Сейчас многие языки разиваются в сторону распараллеливания и тредов. Можно ли это в пхп написать и использовать? Нет, никто не будет писать. Неизвестно даже будет ли UTF-8 и PHP 5.6 вообще…
Ну а Behat клевый.
*упс, PHP 6
Мы только в 2010 увидим «правильные» веб фреймворки, ORM, BDD-фреймворки. Возможно, потому, что это стало возможно только с появлением PHP 5.
Это случается как раз потому, что нашлись люди, которые осознали, что «нет никакой разницы на чем писать говно и никакой разницы на чем писать «конфетку»». Вместо того, чтобы скакать с языка на язык, эти люди делают по максимуму в том сообществе, в котором они выросли и учились.
Начни в свое время рубисты переходит на более интересные языки (а такие были) — не было бы того Ruby коммьюнити, что есть сейчас. Да и рельс бы не было!
Проблема не в языках, а в том, что мы на них пишем и насколько хорошо мы это делаем!
Сейчас многие языки разиваются в сторону распараллеливания и тредов. Можно ли это в пхп написать и использовать? Нет, никто не будет писать.
У многих языков (включая Ruby) давно есть поддержка тредов. Все проекты их примененяют? Нет? А почему? Потому что это не серебряная пуля! Потому что сложность и затратность разработки проектов с активным параллелизмом на основе тредов перекрывает большинство итоговых плюсов подобных проектов. Дешевая альтернатива тредам — событийные системы на основе евент-лупов, а они в Ruby точно так же не развиты, как и треды в PHP! Но это не значит, что Ruby — плохой язык и что всем надо срочно переходить на node.js. Это лишь значит, что для некоторого набора задач node.js с его event-driven натурой подходит больше, чем Ruby.
Ну и по поводу
никто не будет писатьНе так давно многие думали, что и красивого BDD под PHP быть не может и никто его не будет писать!
Все верно
В том то и дело, что PHP не относился к более интересным язык и вообще интересным. На руби остались, да, написали рельсы.
Про треды был просто пример темпа развития PHP (в нем нет даже намеков на
это как в руби).
Если язык не так важен, то почему ни у кого нет желания переходить с других языков писать тот самый качественный код на PHP? потому, что он, как язык, ничем не примечателен и допустил слишком много legacy-программистов и legacy-кода.
За Behat спасибо.
Начни в свое время рубисты переходит на более интересные языки(оффтоп, по-моему, кроме python и не было ничего в то время)
В том то и дело, что PHP не относился к более интересным язык и вообще интересным. На руби остались, да, написали рельсы.
Про треды был просто пример темпа развития PHP (в нем нет даже намеков на
это как в руби).
Если язык не так важен, то почему ни у кого нет желания переходить с других языков писать тот самый качественный код на PHP? потому, что он, как язык, ничем не примечателен и допустил слишком много legacy-программистов и legacy-кода.
За Behat спасибо.
а можно спросить, что не так с поддержкой utf8 у текущей версии PHP?
Для заказчика зачастую никакой, да. Но мы тут говорим о программистах. Любую задачу можно качественно решить и на ASM'е, но отчего-то никто на нем вебы не программирует. Ruby банально удобнее PHP, тут даже холиварить не нужно. Практически все, что появляется нового в PHP уже давно есть в Ruby. Практически все, что появляется в топовых PHP-фреймворках, уже давно есть в Рельсах. При этом зачастую один и тот же функционал выглядит в Рельсах гораздо красивее в плане синтаксиса (посмотрите, например, на валидации в Yii и в Рельсах).
Не могу спорить, что PHP и его фреймворки когда-то дорастут до RoR, но нынешние темпы развития как-то не располагают верить в это…
Не могу спорить, что PHP и его фреймворки когда-то дорастут до RoR, но нынешние темпы развития как-то не располагают верить в это…
Любую задачу можно качественно решить и на ASM'е, но отчего-то никто на нем вебы не программирует.
Ну давайте не будем сравнивать красное с деревянным. Вы же прекрасно понимаете, что драйвера и микроконтроллеры на Ruby/PHP тоже не напишешь. Мы говорим про языки одного уровня. В данном случае, повторюсь: в Ruby нет ничего, что бы было невозможно использовать/написать в PHP!
Ruby банально удобнее PHP, тут даже холиварить не нужно.
Дела вкуса. Я не питаю иллюзий. PHP в достаточной степени ужасен, чтобы его ненавидеть. Но в нем есть все, что нужно чтобы писать и использовать красивые приложения. Нужен синтаксический сахар? Так опять же, есть языки и покрасивее/полаконичнее Ruby.
Практически все, что появляется нового в PHP уже давно есть в Ruby.
Это достоинство коммьюнити, а не языка. Смотрите мой коммент выше! Если бы с Ruby все в свое время многие начали переходить на более интересный язык — ничего бы из того что «уже давно есть в Ruby» не было!
При этом зачастую один и тот же функционал выглядит в Рельсах гораздо красивее в плане синтаксиса (посмотрите, например, на валидации в Yii и в Рельсах).
Не могу спорить, что PHP и его фреймворки когда-то дорастут до RoR.
Посмотрите на Symfony2+Doctrine2. PHP не надо «дорастать до RoR», чтобы писать на нем фрэймворки уровня, а то и лучше (а мне действительно многое в sf2 нравится больше) рельс.
PHP в достаточной степени ужасен, чтобы его ненавидеть.
Вот этим все и сказано.
Если бы с Ruby все в свое время многие начали переходить на более интересный язык — ничего бы из того что «уже давно есть в Ruby» не было
Коммьюнити у PHP во много раз больше, чем у Ruby. А толку от этого мало. Не PHP плох из-за ухода людей, а люди уходят, потому что PHP плох.
И вообще ход мыслей странный. Зачем использовать неудобный язык, если есть удобный, ты его знаешь и имеешь возможность его использовать?
Посмотрите на Symfony2+Doctrine2. PHP не надо «дорастать до RoR», чтобы писать на нем фрэймворки уровня, а то и лучше (а мне действительно многое в sf2 нравится больше) рельс.
Symfony, к сожалению, настолько не знаю, чтобы спорить на его счет, но пока столкновения с ним не вселили веру в победу PHP.
Вот этим все и сказано.
«Bad parts» есть в каждом языке и это ровным счетом ни о чем не говорит.
Не PHP плох из-за ухода людей, а люди уходят, потому что PHP плох.
Люди уходят потому что склонны верить в сказки об идеальных языках и фреймворках. Люди считают, что вот сейчас на PHP они пишут гавно, а перейдя завтра на Ruby они станут штамповать конфетки. Такого нет и не будет. Человеку, неспособному писать красиво на PHP будет в 1000 раз легче писать некрасиво и на Ruby. На node.js сейчас пишутся красивые библиотеки не оттого, что javascript не позволяет писать гавно. В JS гавна на порядки больше, чем в PHP и возможности писать гавно там на порядки выше, да и «bad parts» там в разы больше! Но красивые библиотеки для node.js пишут. Все дело в том, что пишут их вчерашние Ruby девелоперы с опытом «писать код красиво»! Вот и все. Коммьюнити решает, а не язык. PHP уже неоднократно доказал свою состоятельность как языка, на котором можно писать красиво. Мне этого достаточно.
Зачем использовать неудобный язык, если есть удобный
Понятие удобства каждый определяет для себя сам. Для меня удобно все, где с минимальными затратами я могу написать красивый код, который будет работать стабильно. Мою компетенцию в красивом и стабильном коде можете оценить по Behat, jade.php и другим моим проектам.
А многим людям приходится для своего удобства писать новый язык программирования. Но это не значит, что все старые языки сразу становятся ужасными. Это лишь значит, что понятия удобства каждый из нас определяет для себя сам.
Ладно, тут спорить бесполезно… Все доводы сводятся к «на PHP можно тоже писать хороший код»… Просто если что-то можно написать на языке, код на котором займет меньше времени и сил, будет короче и нагляднее без потерь в качестве, я выберу этот язык. У Вас, очевидно, несколько другой взгляд…
У меня просто взгляд человека, который понимает, что не язык развивает коммьюнити, а коммьюнити развивает язык.
Я просто стараюсь сделать мир лучше с теми знаниями, что имею ;-)
Я просто стараюсь сделать мир лучше с теми знаниями, что имею ;-)
Даже если действительно можно писать код на ruby, который займёт меньше времени и сил, чем на php, то на выбор языка влияет не только этот фактор. Даже для разработки «под себя», не говоря уж о заказной.
Навскидку, у PHP больше сообщество (больше вероятность что в твоем коде разберётся разработчик «с улицы», да и стоить он, скорее всего, будет дешевле) и более развитая инфраструктура (больше вероятность, что твой код заработает на произвольном хостинге, да и самих php-хостингов больше, а значит они дешевле)
P.S. А лично мне не показалось что проще, если иметь в виду традиционную веб разработку: многие нужные в вебе вещи в php являются частью языка, а в ruby требуют дополнительных усилий — для банального «hello %username%» нужно чуть ли не свой сервер и шаблонизатор писать или использовать только CGI и писать код типа «puts 200 OK...». Впрочем, это касается многих ЯП общего назначения, от ассемблера до функциональных. Но это вызывает неудобство для перехода с PHP даже для оценки, а вдруг действительно другие языки лучше. Сам язык оценишь — вроде лучше, пытаешься написать hello world и с такими закидонами встречаешься
Навскидку, у PHP больше сообщество (больше вероятность что в твоем коде разберётся разработчик «с улицы», да и стоить он, скорее всего, будет дешевле) и более развитая инфраструктура (больше вероятность, что твой код заработает на произвольном хостинге, да и самих php-хостингов больше, а значит они дешевле)
P.S. А лично мне не показалось что проще, если иметь в виду традиционную веб разработку: многие нужные в вебе вещи в php являются частью языка, а в ruby требуют дополнительных усилий — для банального «hello %username%» нужно чуть ли не свой сервер и шаблонизатор писать или использовать только CGI и писать код типа «puts 200 OK...». Впрочем, это касается многих ЯП общего назначения, от ассемблера до функциональных. Но это вызывает неудобство для перехода с PHP даже для оценки, а вдруг действительно другие языки лучше. Сам язык оценишь — вроде лучше, пытаешься написать hello world и с такими закидонами встречаешься
Вы привели чудесный набор мифов о Ruby =) Если есть желание — в личку могу опровергнуть.
Вы про какую часть коммента? Если про первую (до постскриптума) — то возможно и мифы (откуда-то знаю, но сам анализ точно не проводил специально), а если про вторую, то это личный опыт попыток расширения кругозора.
Про обе.
По первой части:
— у Ruby есть замечательное сообщество, оно меньше по численности, но намного сплоченнее, приезжайте на RubyConfUA 2011 в сентябре, чтобы убедится.
— Инфраструктура Ruby и Rails в разы лучше чем вы можете себе представить: инструменты для развертывания серверов и деплоя applications (Chef, Capistrano), замечательные серверные средства (Unicorn, Passenger), мощнейшие фреймворки для тестирования и CI, в общем, вот так практически для всего (см. ruby-toolbox.com).
— Разработчик на PHP дешевле на старте, но с учетом вышесказанного и учитывая более мощный и читаемый язык, проекты которые больше чем homepage стоят в разы дешевле.
По второй части:
— Никто не пишет puts 200 OK, для низкого уровня есть rack.rubyforge.org/, над rack есть Sinatra и Rails.
— Для банального hello %username% есть Erb, HAML и Liquid
В общем, было бы желание и человек которого поспрашивать можно.
По первой части:
— у Ruby есть замечательное сообщество, оно меньше по численности, но намного сплоченнее, приезжайте на RubyConfUA 2011 в сентябре, чтобы убедится.
— Инфраструктура Ruby и Rails в разы лучше чем вы можете себе представить: инструменты для развертывания серверов и деплоя applications (Chef, Capistrano), замечательные серверные средства (Unicorn, Passenger), мощнейшие фреймворки для тестирования и CI, в общем, вот так практически для всего (см. ruby-toolbox.com).
— Разработчик на PHP дешевле на старте, но с учетом вышесказанного и учитывая более мощный и читаемый язык, проекты которые больше чем homepage стоят в разы дешевле.
По второй части:
— Никто не пишет puts 200 OK, для низкого уровня есть rack.rubyforge.org/, над rack есть Sinatra и Rails.
— Для банального hello %username% есть Erb, HAML и Liquid
В общем, было бы желание и человек которого поспрашивать можно.
Пардон, что в PHP является частью языка и чего нет в Ruby? Если уж на то пошло, ответ сервера формирует не PHP, а, собственно, сервер. Ну, напишите на Ruby puts 'hello %username%', пользуйте mod_fastcgi под тот же апач, в чем проблема-то? В том, что не mod_php?
А если под Ruby имелись ввиду Рельсы, то приведенный пример характерен для чуть более чем 99,999455646% фреймворков.
А если под Ruby имелись ввиду Рельсы, то приведенный пример характерен для чуть более чем 99,999455646% фреймворков.
Парсинг HTTP запроса (метод, параметры, куки, прозрачная реализация сессий), поддержка формирования ответа (поверю на слово, что его формирует сервер, а не интерпретатор, хотя был уверен в обратном, казалось что любое fastcgi приложение передаёт серверу готовый ответ, а сервер, в общем случае, лишь берёт на себя его доставку клиенту), «нативный» шаблонизатор (ещё бы :) ).
Как мне кажется, puts 'hello %username%' будет недостаточно для валидного HTTP ответа, как минимум нужно puts '200' сначала. И это будет, афаик, CGI, а не FastCGI. Для последнего, если не ошибаюсь, нужно писать дополнительную обвязку, пускай и из стандартных компонентов и не на уровне слушания сокетов и работы с процессами/тредами, а чуть повыше, но всё же ниже HTTP.
Имелся в виду как раз чистый язык, если брать рельсы, то нужно сравнивать ror не с голым php, а, например, с symfony (пускай и многое позаимствовавшей у рельс во младенчестве) или zend, yii, kohana,…
Как мне кажется, puts 'hello %username%' будет недостаточно для валидного HTTP ответа, как минимум нужно puts '200' сначала. И это будет, афаик, CGI, а не FastCGI. Для последнего, если не ошибаюсь, нужно писать дополнительную обвязку, пускай и из стандартных компонентов и не на уровне слушания сокетов и работы с процессами/тредами, а чуть повыше, но всё же ниже HTTP.
Имелся в виду как раз чистый язык, если брать рельсы, то нужно сравнивать ror не с голым php, а, например, с symfony (пускай и многое позаимствовавшей у рельс во младенчестве) или zend, yii, kohana,…
Черт, нечаянно начал холивор. Вообще, я хотел сказать только то, что если человек начал писать на этом языке, он ему нравится и в другом языке не хватает нужных ему инструментов — то почему бы не начать на нем работать постоянно. (Вообще я хотел хитро человека захедхантить, но потом глянул в профиль ;)
Холиворить на тему X programming language vs. Y programming language абсолютно бессмысленно, для меня Ruby — кусок хлеба, для кого-то PHP — кусок хлеба и никто никакими аргументами не заставит меня кушать хлеб X, если мне нравится хлеб Y. Но если человек хвалит хлеб X но продолжает есть хлеб Y, то, согласитесь, резонно предложить ему есть, то что ему нравится (при условии что на рынке избыток хлеба X).
Автор Behat молодец и как человек который плотно имел дело с внутренностями capybara хочу пожелать удачи и терпения в этом непростом деле.
Холиворить на тему X programming language vs. Y programming language абсолютно бессмысленно, для меня Ruby — кусок хлеба, для кого-то PHP — кусок хлеба и никто никакими аргументами не заставит меня кушать хлеб X, если мне нравится хлеб Y. Но если человек хвалит хлеб X но продолжает есть хлеб Y, то, согласитесь, резонно предложить ему есть, то что ему нравится (при условии что на рынке избыток хлеба X).
Автор Behat молодец и как человек который плотно имел дело с внутренностями capybara хочу пожелать удачи и терпения в этом непростом деле.
Вот скольку не пытаюсь въехать в суть BDD, как-то не пойму её плюсов перед TDD… Вроде те же тесты по сути…
Человекопонятные. Тесты для того же Behat можно писать в тандеме с заказчиком — и ему спокойно, что вы все правильно оценили, и у вас готовые тесты.
Человекопонятность (почти естественный язык, жаль что не русский) — это базовое свойство BDD или лишь best practice при использовании некоторых фреймворков? То есть BDD это просто смена PHPUnit на Behat или что-то большее? Технически разницу вроде вижу, а вот концептуально…
*То есть переход от TDD к BDD это просто
Это не смена. Хотя и BDD выросло из TDD, TDD никто не отменял и не заменял.
BDD относится к Acceptance Tests, т.е. грубо говоря вы пишите пользовательские сценарии на обычном английском (можно и на русском) языке, given/when/then и автоматическая среда тестирования проверяет что результат соответствует then. Такие вот тесты интерфейса. Классы, объекты и тому подобная функциональная часть никуда не делась, поэтому Unit тесты по-прежнему надо писать с помощью TDD.
Как примерно процесс выглядит хорошо написано тут.
PS: Не знаю почему такой шум вокруг BDD, наверно, кушать хочется всем, а про TDD слушать уже надоело %)
BDD относится к Acceptance Tests, т.е. грубо говоря вы пишите пользовательские сценарии на обычном английском (можно и на русском) языке, given/when/then и автоматическая среда тестирования проверяет что результат соответствует then. Такие вот тесты интерфейса. Классы, объекты и тому подобная функциональная часть никуда не делась, поэтому Unit тесты по-прежнему надо писать с помощью TDD.
Как примерно процесс выглядит хорошо написано тут.
PS: Не знаю почему такой шум вокруг BDD, наверно, кушать хочется всем, а про TDD слушать уже надоело %)
Забыл отметить. В BDD есть интересная особенность. Тесты начинаются не с префикса 'test' (как в PHPUnit и других фреймворках), а начинаются с (или содержат) ensureThat (убедиться что) и should (должно). Это практику хорошо использовать для написания хороших unit тестов тоже, т.е. вместо:
public function testTotalFee{/*php*/}/* @test */
public function totalFeeShouldIncludeOurFeeAndTax{/*php*/}Вы все намешали в одну кучу. BDD — это эволюция TDD в полном смысле этого слова.
На определенном этапе, чтобы привлечь больше разработчиков к тестированию своих продуктов, было решено пересмотреть объект тестирования. Отсюда появился BDD и так называемые «Specification Tests» или просто «specs». Это обычные юнит-тесты со слегка измененным синтаксисом, позволяющим представлять описанные тесты в виде спецификаций тестируемых объектов. Примерами specs фрэймворков являются RSpec/JSpec. И к примеру, RSpec вполне себе заменяет классический TestUnit, которым с каждым днем пользуется все меньше и меньше Ruby разработчиков…
Немногим позже, родилось еще одно ответвление от BDD — так называемые «Scenario Tests». Это тесты, строящиеся вокруг понятия «сценарий» и последовательностей выполняемых шагов для достижения тестируемого состояния системы. Примерами сценарно-ориентированных BDD фрэймворков являются Cucumber/Behat/JBehave. И да, вот scenario-тесты больше подходят для acceptance тестирования, нежели для юнит-тестов.
Вообще, BDD — это практика, объединяющая в себе TDD, DDD и Acceptance TDP. BDD фрэймворки успешно пытаются объединить эти 3 техники в одну систему и ветвятся на 2 самодостаточных стэка: specs тесты и scenario тесты. Первые призваны заменить классические unit тесты, добавив туда описательную часть. Вторые заменяют собой acceptance тесты, превращая функциональные тесты в «поведенческие» сценарии.
На определенном этапе, чтобы привлечь больше разработчиков к тестированию своих продуктов, было решено пересмотреть объект тестирования. Отсюда появился BDD и так называемые «Specification Tests» или просто «specs». Это обычные юнит-тесты со слегка измененным синтаксисом, позволяющим представлять описанные тесты в виде спецификаций тестируемых объектов. Примерами specs фрэймворков являются RSpec/JSpec. И к примеру, RSpec вполне себе заменяет классический TestUnit, которым с каждым днем пользуется все меньше и меньше Ruby разработчиков…
Немногим позже, родилось еще одно ответвление от BDD — так называемые «Scenario Tests». Это тесты, строящиеся вокруг понятия «сценарий» и последовательностей выполняемых шагов для достижения тестируемого состояния системы. Примерами сценарно-ориентированных BDD фрэймворков являются Cucumber/Behat/JBehave. И да, вот scenario-тесты больше подходят для acceptance тестирования, нежели для юнит-тестов.
Вообще, BDD — это практика, объединяющая в себе TDD, DDD и Acceptance TDP. BDD фрэймворки успешно пытаются объединить эти 3 техники в одну систему и ветвятся на 2 самодостаточных стэка: specs тесты и scenario тесты. Первые призваны заменить классические unit тесты, добавив туда описательную часть. Вторые заменяют собой acceptance тесты, превращая функциональные тесты в «поведенческие» сценарии.
Ничего и не намешал %) Я не знал про разделение тестов на «Scenario» и «Specification», но в контексте Behat и вообще как BDD выглядит сейчас, можно говорить что это «Scenario Tests»
BDD — это больше эволюция процесса разработки ПО, а не TDD (замену test на should я бы назвал рекомендацией, а не эволюцией).
Вообще я отвечал куда делся TDD, и последний комментарий — «BDD — это практика, объединяющая в себе TDD, DDD и Acceptance TDP» — в закладки.
BDD — это эволюция TDD
BDD — это больше эволюция процесса разработки ПО, а не TDD (замену test на should я бы назвал рекомендацией, а не эволюцией).
Вообще я отвечал куда делся TDD, и последний комментарий — «BDD — это практика, объединяющая в себе TDD, DDD и Acceptance TDP» — в закладки.
А никто не встречал «Specification Tests» фреймворков для PHP, наподобии Jasmin и jSpec?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP + BDD = Behat, или сказ о чудо-библиотеке