Выпуск №10 — Codeception

Продолжаем выпуски с гостями! Сегодня в записи подкаста приняли участи Михаил Боднарчук @davert (автор Codeception) и Марк Ragazzo (контрибьютор в Yii, Codeception и эксперт по DDD).

Запись получилось достаточно длинной, поэтому мы решили разбить её на два выпуска.

Основной темой первой части стал Codeception — современный фреймворк для тестирования PHP проектов. Поговорим про историю проекта, основные идеи заложенные в Codeception, его киллер-фичи по сравнению с другими системами для тестирования и про вышедшую неделю назад версию 2.1!

Во второй части (т.е. в выпуске подкаста №11) плотно обсудим тему Domain Driven Design (DDD) вообще, и в PHP проектах в частноти. Подписывайтесь в iTUnes или RSS, чтбоы не пропустить следующий выпуск.

Ссылки по теме:

http://codeception.com — современная библиотека для тестирования PHP проектов

https://github.com/Codeception/Codeception/wiki/Who-is-using-it — список наиболее известных проектов, использующих Codeception

http://allframeworks.ru/codeception — неофициальный перевод документации по Codeception

http://codeception.com/06-30-2015/codeception-2.1-is-here.html — обзор свежего релиза Codeception 2.1
http://automated-testing.info — сообщество автоматизаторов

https://medium.com/@WoloxEngineering/ruby-on-rails-continuous-integration-with-jenkins-and-docker-compose-8dfd24c3df57 — хорошая статья

Полная текстовая расшифровка под катом.

Всем привет! Вы слушаете «Пятиминутку PHP» — юбилейный выпуск №10 еженедельного подкаста о новостях из мира PHP, интересных постах в блогах и современных подходах к разработке.

Прошлый выпуск у нас был необычный — мы записывались с гостем в студии. Сегодняшний выпуск вдвойне необычный — в студии 2 гостя. Представлю вам. Михаил Боднарчук, он же @davert…

davert: — Всем привет.

…создатель Codeception, аплодисменты!

И Марк Ragazzo, известный контрибьютор в Yii, Codeception и другие проекты. Марк, привет.

Ragazzo: – Всем привет.

Миша, начнем с тебя. Расскажи немного о себе. Чем ты интересуешься, чем, в основном, занят в мире разработки?

davert: — Занят я в последнее время в целом Codeception и тут так получилось, что мой проект перерос из хобби в что-то общеполезное, и настолько полезное, что мне даже платят за то, что я разрабатываю свой фреймворк для тестирования.

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

Хотя там была длинная история. Сначала было название TestGuy, потому что идея изначально заключалась в том, чтобы описывать все действия пользователя от лица какого-то тестировщика и я назвал его TestGuy. Потом, после общения с некоторыми феминистками, я понял, что нужно придумывать, что-то более креативное, более нейтральное и появилось такое название, как Сodeception. Мне просто понравилось, что можно совместить слово «perception» и «code», и в итоге в этой прикольной комбинации получается замечательное слово, при этом достаточно популярное. В среде разработки рано или поздно человек написавший какую-то рекурсивную строчку кода, которая пишет сама код, понимает, что он написал Сodeception, но сodeception.com уже забит мной, поэтому кажется, с именем получилось неплохо.

Изначально я хотел делать проект, как плагин к Symfony 1, то есть вы представляете, насколько это были древние времена, когда еще Symfony 1 существовала. Но в какой-то момент все PHP сообщество переходило на PHP 5.3 и началось появляться очень и очень много фреймворков. И я решил, как-то не привязываться к одному, и попытаться сделать что-то мегауниверсальное. И сейчас мы имеем, что Codeception – это какой-то кухонный комбайн, который умеет Laravel тестирование и Symfony тестирование, и Zend, и Selenium, и Yii, и тесты через PHPUnit. И все это мы держим в коробке, и предоставляем разработчикам, чтобы они не парились, и не изобретали свои велосипеды.

У тебя просто уникальная ситуация. Ты можешь работать над своим любимым проектом, open source проектом, и еще деньги за это получать! Буквально по пальцам таких людей пересчитать: Линус Торвальдс и ты?)

davert: — Таких чуть больше, но в целом, спасибо, спасибо, что причислил меня к лику Линуса Торвальдса.

Ты уже в целом рассказал основные фичи Codeception, но что самое крутое, чтобы ты отметил, чего нет в других фреймворках для тестирования?

davert: – По другим фреймворкам для тестирования, что есть из ближайших аналогов, это только Behat и PHPUnit на котором можно выстроить подобную систему. Что принципиально уникально? То, что разработчик минимально думает о том, как ему написать этот тест, что ему тестировать. Codeception представляет огромный набор модулей, которые просто нужно интегрировать в проект, сказать, что мы используем базу данных, мы используем Symfony. Doctrine, и он дальше может писать совершенно линейный, простой код тестов. То есть код будет читабельный, его легко будет обновлять, модифицировать под нужные проекты. Не будет такой ситуации, что приходит разработчик, читает тесты и нечего не понимает, что тут происходит. Тесты сделаны таким образом, чтобы они были максимально читабельны.

На самом деле эта фича про максимальную читабельность для тестов, она, в принципе, существует и в Behat, которая, по сути, является системой, которая берет тестовый файл и запускает его в виде теста. Но в Codeception, что я неоднократно говорил, мы стараемся еще делать универсальный интерфейс для команд, которые будут использоваться в тестах, чтобы пользователь легко мог написать тест, как для Selenium, так и для, допустим, Symfony, при этом используя один и тот же API. Чтобы одна и та же команда могла выполняться, и там, и там. Например, команда $I->amOnPage() открывает страницу, но в зависимости от того, какой модуль мы ей выберем, оно откроется или в браузере, или внутри Symfony, не используя веб-сервер. Допустим, если у нас там появилось некоторое количество функциональных тестов, мы можем легко из них сделать приёмочный тест и гонять через браузер, или наоборот. То есть мы легко можем выделять тесты в группы, перетаскивать из них туда-сюда.

Ты упомянул функциональные тесты, приёмочные тесты. А юнит-тестирование можно сделать с Codeception?

davert: – Да, я его упомянул мало, потому что решил, зачем нам изобретать велосипед, мы возьмем PHPUnit. Действительно, под коробкой в Codeception живет огромнейший, мощнейший, крутейший PHPUnit, который, в принципе, работает, как обычный. Codeception, конечно, добавляет туда некоторые фичи. Например, возможность тестировать базу данных, то есть писать, по сути, писать интеграционные тесты. Но в целом, каких-то кардинальных дополнений к юнит-тестированию нет. В принципе, PHPUnit для этого и так замечательный. Зачем что-то придумывать, если оно и так работает. Так что, если существует, какой-то проект, в котором есть только юнит-тесты и написан на PHPUnit, то в принципе, есть смысл мигрировать на Codeception, скопировать эти юнит-тесты в папку «Unit», которую создаст инсталлятор Codeception. А потом написать функциональный, приемочный, и запускать их уже все вместе.

Очень удобно продумано. А для каких проектов ты рекомендуешь использовать именно Codeception? Получается, что для любых? Какие уже используют из известных?

davert: – Да, наверное, все-таки для любых. Это хорошая идея. Из того, что я мониторю по Twitter лентам, он уже достаточно популярный. Например, в WordPress сообществе, Joomla сообществе, то есть в тех приложениях, у которых много легаси кода и которые, по сути, нельзя протестировать юнит или на функциональном уровне. Здесь Codeception очень поможет тем, что в нем очень удобно реализовано приёмочное тестирование.

Я, например, совершенно не сторонник такого подхода, что код должен быть обязательно тестируемый. Что если вы не можете протестировать свой код, вы должны обязательно взять его и переписать. Нет, прежде, чем взять и переписать свой код, вы должны покрыть его приёмочными тестами, чтобы быть уверенным, что если вы этот код перепишите, весь функционал будет работать. Поэтому Codeception отлично подходит для таких проектов, где ему нужно сначала покрыть функционал, а потом вы можете рефакторить этот код или не рефакторить. Пусть ваш сайт на WordPress продолжает работать. Главное, что вы будете уверенны, что этот сайт работоспособный. Легаси проект – это одна из возможностей, просто вы не забывайте о том, что Легаси проект тоже нужно тестировать.

В целом, на любые проекты, которые, допустим, начинают разрабатываться на фреймворках, желательно современных, Yii 2, Symfony, Laravel, …, на них легко начинать, используя Codeception, он сразу внедрится в проект и интеграция происходит быстро и безболезненно.

Где он используется уже? Я не скажу, что я хорошо осведомлен о том, кто его использует. Я узнаю об этом спонтанно. Из таких известных компаний я знаю «DepositPhotos», «Magma Digital» и другие. Есть небольшой списочек, но в целом, просто иногда случайно узнаю о том, что кто-то его использует и иногда приглашает провести тренинги, и узнать, как его правильно использовать.

Ragazzo: — Я тебе, кстати, случайно могу подсказать, насколько я знаю, ты же знаешь Александра Лисаченко?

davert: – Да.

Ragazzo: — Насколько я знаю, они у себя тоже используют Codeception.

davert: — Да, я от него слышал, но это было год назад. Я не знаю, как у них сейчас.

Ragazzo: — Я слышал пару месяцев назад. Видимо нечего не изменилось.

davert: – Прикольно, прикольно.

А что за проект у Александра?

Ragazzo: – У них alpari, alpari.ru Большие деньги на PHP, что уникальность. У них что-то связанное с биржами, трейдинг. Я, в принципе, особо не вникал. Там сложный домен. Все эти дела. Плюс, кстати, следует упомянуть, поскольку Codeception является по умолчанию тестовым фреймворком Yii 2, то многие проекты на Yii 2, собственно, его используют.

Да, вот это хорошее замечание. Yii 2 выбрал Codeception, как основной. А для тех, кто еще не начал тестировать, Миша, что ты посоветуешь? Как начать, замотивируй?

davert: – Я обычно не занимаюсь тем, что мотивирую людей. Я просто озвучиваю вот такую замечательную картинку. Представьте, пятница, вечер. Вы написали последнюю строчку вашего замечательного кода и вы деплоете все это на production. Суббота, утро, вы ещё не уходили с работы. Вы разбираетесь, почему у вас на production все еще белая страница, почему у вас еще нечего не работает? И где-то в субботу, ближе ко второй половине дня, когда вы разобрались, что там, все-таки, не сработало, вы задумываетесь, а почему я не написал этот грёбаный тест? Почему я не проверил перед тем, как заливать? Тут других аргументов не нужно!

Необходимость в тестах возникает именно в те мгновения, на том проекте, из которого изначально вырос Codeception, потом к нему пришли новые разработчики и они долго, долго ругались на то, что там постоянно тесты падают, их постоянно не понятно, как их поддерживать и, вообще, давайте эти тесты нафиг отключим. На что CTO проекта сказал: «Нет, нет. Тесты спасли нам несколько раз жизнь, так что разбирайтесь и чините».

Хорошая, поучительная история. Вернемся немного к технической стороне. Был Codeception версии 1 достаточно долго и потом появился Codeception версии 2, что принципиально нового? Какие уроки ты вынес в процессе работы над проектом? Какие-то архитектурные изменения? Расскажи поподробней.

davert: – Да, там было достаточно сильное изменение, но я старался, чтобы все изменения происходили под капотом и чтобы пользователи так принципиально не видели, что происходит внутри. А по сути, что изменилось? Codeception стал больше похож на PHP-тестинг фреймворк, а не на, допустим, на Gherkin interpreter, как это было в Behat.

Изначально архитектура была подобна на Behat. Каждая наша команда записывается в сценарий, а потом этот сценарий пошагово выполняется. Сейчас же все команды «я открываю страницу», «я кликаю на кнопку», «я заполняю поле» — они выполняются непосредственно в самом коде. Это значит, что мы можем работать с этим кодом достаточно свободно. Мы можем там использовать переменные, использовать if, использовать циклы, если это необходимо и в случае, если что-то упало, мы получим очень четкий stack-trace к этому месту. Наверное, это самое значительное нововведение Codeception версии 2 и, если честно, я бы еще упомянул про Codeception версии 2.1, потому что я уже не помню, что было нового и революционного в версии 2, так как она вышла год назад. Зато я прекрасно помню, что произошло в версии 2.1, потому что она вышла только в понедельник. И когда я, собственно, в 7 утра заливал релиз на сайт, я начал вспоминать, что да, да, там очень много чего интересного, о чем стоило бы и рассказать.

Во-первых, я добавил очень простой, но тем не менее, классный инструмент, называется — рекордер. Это extension, который для всех приёмочных тестов, которые работают через Selemium WebDriver или PhantomJS, он сохраняет скриншоты этих тестов на каждом шагу. Если тест упал, вы можете легко просмотреть пошагово, как он выполнялся, что было заполнено, что было кликнуто, на какие страницы перешли и на финальном шаге, где тест упал, вы увидите скриншот и сравните его с тем, что вы хотели увидеть. Это очень, очень полезно. Допустим, если ваши приёмочные тесты упали на вашем CI сервере. А они там постоянно падают, честно говоря. И еще не менее полезно, если ваши тесты, вы пишите их без использования браузера. Например, вы используете PhantomJS и вы не видите, что происходит на странице. Так что в режиме слайд-шоу вы потом можете просмотреть.

Из таких мене ярких изменений, которые просто работают, в Codeception внедрен Dependency Injection. Наверное, я не буду объяснять, чем он принципиально классный, потому что это, скажем так, для продвинутых пользователей Codeception он будет интересен.

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

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

Уточняющий вопрос. Под PhantomJS, если запускаем, ты все равно можешь скриншоты снять?

davert: – Да, конечно. Все равно это выполняется в виде браузера, просто он не открывает окно, но сами скриншоты, они снимаются. Там, конечно, совершенно будут не системные шрифты, верстка, скорей всего, разъедется, но они будут, скиншоты будут.

Отлично. Слушай, интересная штука. А какие у тебя планы на будущее? Куда дальше развивать? Какие фишки стоит ждать, такие классные, типа скриншотов?

davert: – Боюсь, пока таких глобальных планов на будущее нет. Возможно, правда у меня есть такая мечта, написать Codeception на JS, но вы пока никому об этом не говорите. Это все пока еще на уровне мечтаний. А в самом Codeception мечта, пока, все-таки, стабилизировать то, что у нас есть, сделать версию 2.1 общедоступной и сделать ее стандартом.

Я уверен, что разработчики, которые будут уже писать по тем гайдам, которые я адаптировал к 2.1, их код будет намного проще, намного понятнее. У них будет намного больше возможностей. Выделяешь какие-то общие моменты из тестов в PageObject, StepObject…, короче, делать тесты чистыми, приятными и понятными для разработчиков, для тестировщиков, для всех.

А на сколько просто перейти на 2.1? Там совместимость сохранена или придется много переделывать?

davert: – Там, практически, нечего не нужно переделывать. Нужно просто перестроить тестер-классы командой builld. Она, по сути, все сделает и, возможно, при тестовом запуске выпадет exception, который расскажет вам, что когда-то этот API работал, но сейчас, пожалуйста, измените чуть конфигурацию, чтобы у вас все заработало и будет у вас все хорошо. Просто прочитайте exception, выполните команду build и все.

Очень просто. Так что давайте, все ставим Codeception 2.1 и вперед. А для тех, кто хочет углубиться, расскажи, может можно как-то помочь проекту, прислать пулреквесты, может документацию где-то подправить?

davert: – Да, да. Все это актуально. Issues присылать их не надо, их у нас и так очень много :)

Кстати, я хочу немного рассказать про команду. Если еще год назад работал исключительно один я, то сейчас я стараюсь, чтобы все больше и больше людей было втянуто в проект. Нас уже 7 человек и мы стараемся распределяться таким образом, что каждый занимается своим модулем. Допустим, я не использую Laravel. У нас есть прекрасный человек из Нидерландов, который поддерживает все 2 модуля: Laravel и Lumen. У нас есть человек, который занимается Zend’ом, есть человек, который занимается Falcon’ом. У нас нет человека, который занимается Symfony модулем и если вы симфонист и используете Codeception, это будет замечательной помощью, если вы к нам присоединитесь. Конечно, у нас еще сеть Саша Макаров, который поддерживает связь между Codeception и Yii.

Если вы хотите присоединится к нашей команде, в идеале вам надо знать Symfony, а не в идеале просто присылать pull request, чинить наши баги, потому что да, они появляются, тут без этого никак. И что тоже немаловажно, просто помогайте другим новичкам освоиться в Codeception. У нас есть несколько форумов на которых можно задавать вопросы: http://phptest.club и http://automated-testing.info — там очень много новичков. У них очень много вопросов. Увы, я не справляюсь с тем, чтобы всем им ответить. Было бы неплохо, чтобы как-то коллективно помогали людям. В какой-то момент, возможно, они помогут и нам.

И это правильно! Марк, ты, например, используешь Codeception в своих проектах? Помогаешь в развитии?

Ragazzo: – Я помогал раньше, даже помню, когда мы с davert-ом начали общаться в первый раз на хабре, это был, наверное, февраль 2013 года. Тогда Codeception был еще 1.5 или даже 1.4.3. С тех пор, в принципе, там много чего сделали. Пропихнули формат тестов в виде классов. Раньше они были как набор инструкций, а потом пропихнули в виде cest — это обычный класс, но более удобный для написания тестов. И поначалу я поддерживал Yii 1 модуль. Правда, к сожалению, в связи с архитектурой Yii 1, который использовала где-то exit(), где-то еще что-то, не очень было удобно. Потом в Yii 2 помогал, консультировал по поводу опыта моего работы с Codeception. Как я понял, сообщество использует модуль для Yii 2, просто он для Yii 2 удобен!

Поскольку davert тут еще упоминал про Behat, я бы его ещё каверзными вопросами помучал. Почему-то все, в принципе, сравнивают Behatи Codeception, и столько холиваров было на эту тему, но, в принципе, это две разные вещи. davert может сейчас объяснить нам это (если считать Behat отдельно от mink).

davert: — Behat отдельно от mink — это всего лишь, ты можешь меня поправить, это просто парсер текстового документа, котрый написан в специальном формате Gherkinа, который каждой строке этого документа присваивает запуск какой-либо команды. Что ты напишешь в эту команду, это абсолютно твое дело. Тебе главное сделать, чтобы прошло сопоставление один-к-одному, строка к команде. И вот Behat , по сути, нечего не дает, кроме этого парсера.

Конечно, там есть раннер, есть какой-то набор, что необходимо для любого тестового фрейворка, но все, что каким образом тест работает внутри, это все лежит на тебе. В Codeception принцип совершенно другой. То, как тест работает внутри, это все лежит на нас, на Codeception. Расширять его, конечно, можно, и можно дополнять, но мы стараемся сделать таким образом, чтобы 90% того, что может пригодиться в работе, уже было написано.

Ragazzo: — В целом, ок, но я немного другое имел ввиду. Именно про кардинальное отличие Behat и Codeception. Дело в том, что Codeception — это именно фреймворк для тестирования, fullstak, а Behat — он ориентирован больше на BDD, так называемый Behavior-Driven Development. В принципе, люди, которые знакомы с BDD, они понимают, что такое Behavior-Driven Development и что такое именно сценарий, user story и все прочие. Поэтому Behat использует понятие user story для описания бизнес спецификаций и требований, которые должен выполнять ваш код. Кто интересуются, могут посмотреть еще очень много презентаций и статей автора Behat или почитать о Cucumber.

davert: – Тут я согласен, если у вас команда нацелена на BDD, а таких к счастью или к сожалению, я не знаю, их немного, то да, Behat – это как раз инструмент для BDD разработки. Но реальность такова, что его, как и Cucumber большинство, все-таки, используют для обычного, банального тестирования.

Ragazzo: — Да, в целом это так. Я даже в следующей теме про DDD коснусь того, как BDD состыкуется с ним и как именно Behat помогает писать эти user story. Но, да, поскольку именно немного людей занимаются именно BDD, то все как-то спохватились. Ок, есть Behat, есть mink, давайте тестировать страницы, поэтому получилось так, что перекос пошел в ту сторону.

Марк, в двух словах, что такое mink для наших слушателей?

Ragazzo: – про mink, наверное, лучше расскажет Михаил. Если в двух словах, то mink — это библиотека, написанная автором Behat, которая помогает использовать Behat для приёмочного тестирования вашего приложения, с точки зрения интерфейса пользователя. Михаил, продолжай.

davert: – Если немного дополнить — это слой абстракции, который позволяет запускать тесты в разных окружениях, через Selenium, через Guzzle (то есть безбраузерный http-клиент) и может еще что-то, то есть это, в принципе то, что когда-то использовал Codeception для своей работы, чтобы иметь один и тот же API доступа. Но в итоге получается, что мы написали свой слой и у нас оно интегрировано. Mink, в свою очередь, остается такой прослойкой, срединой API, которая легко встраивается, как в Behat, так и непосредственно в PHPUnit. К сожалению, я бы не сказал, что сейчас проект активно развивается. Я могу ошибаться, конечно, но мне кажется, что mink немного outdated.

Ragazzo: – Насколько я еще помню, ситуация изменилась после того, как вышел WebDriver от Facebook и вот эти многочисленные костыли и надстройки, они как-то оказались неактуальны и все перешли на WebDriver. Не все, конечно, но переходят.

davert: – mink до сих пор его не поддерживает.

Ragazzo: – Видимо поэтому и не использует. Ладно, сейчас мы тут холивар устроим, потом нам автор Behat еще получше холивар устроит :)

davert: – Припомнит еще…

Кстати, вебдрайвер от Facebook, это сейчас самое-самое актуальное? Как считаете?

davert: – Сейчас это единственная библиотека для работы с Selenium, которую вообще стоит рекомендовать. Так исторически сложилось, что команда Selenium, они не выпускали и не выпустили официального клиента для PHP.

Была куча, куча этих клиентов, Они начали вначале развиваться в виде PHPUnit Selenium Extesion и, честно говоря, очень много проектов сделано с помощью его, но там используется очень старый API и он совершенно не стандартизированный и не документированный. Я очень сочувствую тем людям, которым приходится делать приёмочное тестирование средствами, исключительно PHPUnit, потому что никакой помощи со стороны сообщества Selenium, ни со стороны других пользователей они не получают и, вообще, как работает этот extension, наверное, знает только Sebastian Bergmann (может даже и он не знает).

Как альтернатива, появились независимые библиотеки, потому что была очень тесная привязка к PHPUnit и хотелось бы использовать Selenium напрямую. Появились библиотеки от Instaclik, от Element-34. Они, я не могу точно сказать, как они использовали этот API, но у них, в принципе, все работало, но работало достаточно коряво, поэтому их развелось 2-3 штуки и их самая большая проблема, это их плохая документация, и то, что они совершенно нестандартные в том плане, что они никак не связаны с проектом Selenium и нечего общего в их использовании нет.

Откуда же появились эти библиотеки? Когда-то Facebook написал свою библиотеку для работы с вебдрайвером, но сделал ее настолько корявой, что Instaclik и Element-34 начали туда присылать пачи. В Facebook тогда не знали, как разрабатывать проект в opensource и просто оставили эти форки. Пачи ядро не принимали. Потом, в один прекрасный день, кажется, это было 2 года назад, они удалили все, что они наделали в своей старой библиотеке и сделали новую. В чем прелесть этой новой библиотеки Facebook? Чем она такая классная? Тем, что она полностью повторяет API, который использует официальная Java библиотека для Selenium. Таким образом любая проблема решается тем, что можно нагуглить решение на Java, скопировать код, чуть ее поправить, доставить знаков долларов и она у вас заработает на PHP. Очень полная, очень хорошо проработанная библиотека и поэтому Codeception ее использует. И пока мы так достаточно удовлетворены результатом, я вижу, что оно развивается и всем, даже тем, кто не использует Codeception, но пишет приёмочные тесты очень рекомендую на нее перейти.

А вот такой еще интересный вопрос. А вы видели проекты или может сами участвовали, PHP проекты, в которых тесты пишут на другом языке, например на Java или даже на Ruby?

Ragazzo: – У нас есть. У нас QA именно использует Java и силениум. Девушка пишет автоматизированные тесты, но для этого нужно, чтобы это был такой QA-программист, чтобы он понимал, что такое многопоточность, когда, например, надо тесты запускать все вместе. Бывают некоторые конфликты по памяти и прочие вещи. У нас так сложилось, что именно на Java. Пробовали и на PHP что-то писать, но именно девушка QA осталась на Java, на Selenium.

davert: — Известный проект Wikipedia написан, как мы знаем, на движке Wikimedia на PHP, но они набрали тестировщиков рубистов, которые им сделали Cucumber. Если вы изучаете Cucumber, рекомендую посмотреть или Behat, посмотреть то, как у них выполнены тесты. Они очень красивы и можете многому научиться, просто читая их код.

Что же, про тестирование достаточно много поговорили. Предлагаю перейти к следующей нашей теме…

И тут, в традициях лучших сериалов, на самом интересном месте возникает фраза: «Продолжение следует». Дело в том, что запись получилась достаточно длинной и мы решили разбить ее на 2 выпуска подкаста. В следующем выпуске, который сейчас в обработке, мы плотно поговорим про Domain Driven Design. Не пропустите.