Содержание

Выпуск №10 — Codeception — Пятиминутка PHP

Продолжаем выпуски с гостями! Сегодня в записи подкаста приняли участи Михаил Боднарчук @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. Не пропустите.

Тестирование: Настройка тестового окружения | Полное руководство по Yii 2.0

0 follower

Примечание: Данный раздел находится в разработке.

Yii 2 официально поддерживает интеграцию с фреймворком для тестирования Codeception, который позволяет вам проводить следующие типы тестов:

  • Модульное тестирование — проверяет что отдельный модуль кода работает верно;
  • Функциональное тестирование — проверяет пользовательские сценарии через эмуляцию браузера;
  • Приёмочное тестирование — проверяет пользовательские сценарии в браузере.

Все три типа тестов представлены в шаблонах проектов yii2-basic и yii2-advanced.

Для того, чтобы запустить тесты, необходимо установить Codeception. Сделать это можно как локально, то есть только для текущего проекта, так и глобально для компьютера разработчика.

Для локальной установки используйте следующие команды:

composer require "codeception/codeception=2.1.*"
composer require "codeception/specify=*"
composer require "codeception/verify=*"

Для глобальной установки необходимо добавить директиву global:

composer global require "codeception/codeception=2.1.*"
composer global require "codeception/specify=*"
composer global require "codeception/verify=*"

Если вы никогда не пользовались Composer для установки глобальных пакетов, запустите composer global status. На выходе вы должны получить:

Changed current directory to <directory>

Затем <directory>/vendor/bin добавьте в переменную окружения PATH.

После этого можно использовать codecept глобально из командной строки.

Примечание: глобальная установка позволяет вам использовать Codeception для всех проектов на компьютере разработчика путём запуска команды codecept без указания пути. Тем не менее, данный подход может не подойти. К примеру, в двух разных проектах может потребоваться установить разные версии Codeception. Для простоты все команды в разделах про тестирование используются так, будто Codeception установлен глобально.

Настройка веб-сервера Apache ¶

Если вы используете Apache и настроили его как описано в разделе «Установка Yii», то для тестов вам необходимо создать отдельный виртуальный хост который будет работать с той же папкой, но использовать входной скрипт

index-test.php:

<VirtualHost *:80>
    DocumentRoot "path/to/basic/web"
    ServerName mysite-test
    <Directory "path/to/basic/web">
        Order Allow,Deny
        Allow from all
        AddDefaultCharset utf-8
        DirectoryIndex index-test. php
        RewriteEngine on
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule . index-test.php
    </Directory>
</VirtualHost>

Так мы укажем веб серверу перенаправлять все запросы на скрипт index-test.php. > Note: Обратите внимание, что здесь мы указываем параметр DirectoryIndex, помимо тех параметров, которые были указаны для первого хоста. Это сделано с той целью, чтобы при обращении к главной странице по адресу mysite-test также использовался бы скрипт index-test.php.

Обзор

Go to Top

Модульные тесты

Found a typo or you think this page needs improvement?
Edit it on github !

кодецепция | Документация PhpStorm

PhpStorm обеспечивает поддержку выполнения модульных, функциональных и приемочных тестов с помощью среды тестирования Codeception версии 2.2.0 и выше.

Перед началом работы

Убедитесь, что интерпретатор PHP настроен в PhpStorm на странице PHP, как описано в разделах Настройка локальных интерпретаторов PHP и Настройка удаленных интерпретаторов PHP.

Загрузите и установите Codeception

Прежде чем начать, убедитесь, что Composer установлен на вашем компьютере и инициализирован в текущем проекте, как описано в диспетчере зависимостей Composer.

Загрузите и установите Codeception вручную

  • Загрузите codeception.phar со страницы установки Codeception и сохраните его в корне проекта, где впоследствии будет использоваться Codeception.

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

Загрузите и установите Codeception с Composer

  1. Внутри composer.json добавьте запись зависимости codeception/codeception в раздел require или require-dev . Space»> Ctrl+Пробел , чтобы получить завершение кода для имени и версии пакета.

  2. Выполните одно из следующих действий:

    • Щелкните ссылку Установить в верхней части панели редактора.

    • Если включена проверка неустановленных пакетов Composer, PhpStorm выделит объявленные зависимости, которые в данный момент не установлены. Нажмите Alt+Enter и выберите, хотите ли вы установить конкретную зависимость или все зависимости сразу.

Узнайте больше об установке Codeception на официальном сайте Codeception.

Щелкните рядом с записью пакета в поле редактора composer.json, чтобы перейти на соответствующую страницу настроек и настроить Codeception вручную.

Интеграция Codeception с PhpStorm в проект

Если вы используете локальный интерпретатор PHP, PhpStorm автоматически выполняет первоначальную настройку Codeception. В случае удаленных интерпретаторов PHP требуется ручная настройка Codeception.

Сгенерируйте файл конфигурации codeception.yml

Установив Codeception, вам необходимо инициализировать его в своем проекте, сгенерировав файл конфигурации codeception.yml.

Автоматическая настройка Codeception

  1. Сохраните файл конфигурации codeception.yml или codeception.dist.yml в корне проекта.

  2. Установите Codeception с Composer.

PhpStorm создаст конфигурацию локальной платформы на странице Test Frameworks и конфигурацию запуска/отладки Codeception.

Настроить Codeception вручную

  1. В диалоговом окне настроек ( Ctrl+Alt+S ) перейдите в PHP | Тестовые рамки.

    На открывшейся странице Test Frameworks щелкните в центральной панели и выберите тип конфигурации из списка:

    • В локальных конфигурациях используется интерпретатор PHP проекта по умолчанию, подробности см. в разделе Интерпретаторы CLI проекта по умолчанию.

    • Для использования Codeception с удаленным интерпретатором PHP выберите в открывшемся диалоговом окне одну из конфигураций: целевая среда. Например, если вы установили Codeception через Composer, исполняемый файл хранится в vendor/bin/codecept. Нажмите рядом с полем «Путь к каталогу Codeception» или полем файла phar. PhpStorm определяет версию Codeception и отображает ее под полем.

    • В области Test Runner назначьте файл конфигурации YML, который будет использоваться для запуска и выполнения сценариев.

      По умолчанию Codeception ищет файл конфигурации codeception.yml или codeception.dist.yml в корневой папке проекта. Вы можете назначить пользовательский файл конфигурации.

      • Снимите флажок Файл конфигурации по умолчанию, чтобы Codeception использовал файл конфигурации codeception.yml или codeception.dist.yml из корневой папки проекта. Если такой файл не найден, выполнение теста завершается ошибкой, поэтому может быть надежнее явно указать файл конфигурации.

      • Установите флажок Файл конфигурации по умолчанию, чтобы указать собственный файл конфигурации YML. Позже этот файл будет использоваться по умолчанию во всех конфигурациях запуска/отладки Codeception.

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

Создание теста Codeception для класса

  1. Откройте диалоговое окно «Создать новый тест PHP», выполнив любое из следующих действий:

    • В главном меню выберите Файл | Новый. Затем выберите PHP Test | Модульный тест Codeception или PHP-тест | Codeception Functional Test из контекстного меню. N"> Alt+Insert или щелкните правой кнопкой мыши класс PHP, который нужно протестировать, и выберите New | PHP-тест | Модульный тест Codeception или новый | PHP-тест | Функциональный тест кодового восприятия.

    • В редакторе тестируемого класса PHP поместите курсор на определение класса. Затем нажмите Alt+Enter и выберите «Создать новый тест» во всплывающем меню. Таким образом, вы можете сгенерировать тест для класса PHP, определенного среди нескольких классов в одном файле PHP.

      Чтобы создать тест для определенного метода, поместите курсор в объявление метода. Выбранный метод будет автоматически выбран в списке методов диалогового окна «Создать новый PHP-тест».

  2. Откроется диалоговое окно «Создать новый тест PHP».

    Укажите параметры сгенерированного теста:

    • Шаблон тестового файла, то есть шаблон, на основе которого PhpStorm будет генерировать тестовый класс. Убедитесь, что в списке шаблонов тестовых файлов выбраны Codeception Unit или Codeception Functional.

    • Имя тестового класса. PhpStorm автоматически составляет имя из имени производственного класса как <производственный класс>Test.php (для модульного тестирования Codeception) или <производственный класс>Cest.php (для функционального тестирования Codeception).

    • Папка для файла тестового класса, которая автоматически предлагается на основе содержащего каталога и пространства имен производственного класса, настроенного корня тестовых источников и его префикса пакета psr-4 или значения тестов , указанного в Файл конфигурации codeception. yml.

      Чтобы указать другую папку, щелкните рядом с полем Каталог и выберите соответствующую папку.

    • Пространство имен, которому будет принадлежать тестовый класс, которое автоматически предлагается на основе содержащего каталога и пространства имен производственного класса, настроенного корня тестовых источников и его префикса пакета psr-4 или пространство имен значение, указанное в файле конфигурации codeception.yml.

    • Методы производственного класса, для которых создаются заглушки тестовых методов. Установите флажки рядом с требуемыми методами производственного класса. Чтобы включить унаследованные методы от родительских классов, установите флажок Показать унаследованные методы.

      PhpStorm автоматически составит имена тестовых методов как test . Вы можете настроить шаблоны кода, используемые для создания заглушек методов тестирования, на вкладке «Код» на странице настроек «Файл и шаблоны кода».

После создания теста вы можете вернуться к рабочему классу, выбрав Навигация | Перейти к испытуемому. Дополнительные сведения см. в разделе Навигация между тестом и его испытуемым.

Запуск и отладка тестов Codeception

Сведения о написании тестов Codeception см. в разделах Модульные тесты, Приемочные тесты и Функциональные тесты.

Запуск или отладка тестов Codeception

  • В окне инструментов Project выберите файл или папку для запуска тестов и выберите Run ‘<файл или папка>‘ или Debug ‘<файл или папка>‘ в контекстном меню на выбор:

    PhpStorm создает конфигурацию запуска по умолчанию и запускает с ней тестовый сеанс запуска или отладки.

Сохранение автоматически сгенерированной конфигурации по умолчанию

Запуск или отладка тестов с использованием ранее сохраненной конфигурации запуска/отладки

Создание пользовательской конфигурации запуска/отладки

  1. тесты для запуска и выберите Создать конфигурацию запуска в контекстном меню. В качестве альтернативы выберите «Выполнить» | Отредактируйте конфигурации в главном меню, затем щелкните и выберите Codeception из списка.

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

Мониторинг результатов тестов

PhpStorm показывает результаты выполнения тестов на вкладке Test Runner окна Run tool.

Вкладка разделена на 2 основные области:

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

  • В правой части отображаются необработанные выходные данные Codeception.

Автоматический запуск тестов Codeception

Вы можете настроить автоматический повторный запуск тестов PhpStorm при изменении затронутого кода. Этот параметр настраивается для каждой конфигурации запуска/отладки и может применяться к тесту, тестовому файлу, папке или составному набору тестов в зависимости от области теста, указанной в этой конфигурации запуска/отладки.

  1. Запустите тесты.

  2. На вкладке Test Runner нажмите кнопку-переключатель на панели инструментов:

  3. Дополнительно нажмите кнопку и установите задержку запуска тестов при изменении кода:

Последнее изменение: 21 Апрель 2023 г.

Behat PHPSpec

Введение в Codeception. Почему тестирование важно? | Зишан Башир | tajawal

Опубликовано в

·

Чтение через 5 мин.

·

24 апреля 2018 г.

https://codeception.com/

Почему важно тестирование?

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

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

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

Что может дать тестирование?
  • При рефакторинге обеспечивает быстрый автоматизированный способ тестирования вашего кода.
  • Модульные тесты доказывают, что ваш код действительно работает.
  • Если вы не можете написать тест на что-то, значит, вы этого не понимаете.
  • Если вы или другой разработчик измените код, есть шанс нарушить ожидаемое поведение, поэтому мы можем решить эту проблему, запустив модульные тесты.
  • Потратив немного времени на написание тестов, вы сэкономите часы на отладке в будущем.

Никакое количество тестов не может доказать правильность программного обеспечения, один тест может доказать неправильность программного обеспечения ~ Амир Гарай

  • Мы можем справиться с неожиданными сценариями ввода.
  • Стресс-тест, чтобы убедиться, что приложение может выдерживать высокие нагрузки.
  • Ошибки, обнаруженные ранее, легче исправить, ошибки, обнаруженные позже, обычно являются результатом множества изменений, и мы не знаем, какая из них вызвала ошибку.

Что нельзя сделать с помощью тестирования?
  • Тесты отлично подходят для поддержки поддерживаемого приложения, но они не могут проверить поведение приложения от начала до конца.
  • Тесты не улучшают качество, на самом деле это делают разработчики.

Что такое Codeception?

Codeception — это фреймворк, написанный на PHP для тестирования приложений, и его многофункциональный тестовый фреймворк на основе известной PHPUnit Framework.

~ Элегантное и эффективное тестирование для PHP ~

Он может управлять модулем, функционалом и приемкой для веб-приложения, давайте обсудим наборы Codeception.

Suites of Codeception

Главное преимущество Codeception в том, что нам не нужно работать только с одним типом тестирования, Codeception предлагает идею наборов (коллекции), Codeception по умолчанию состоит из трех наборов, которые следующие :

  1. Модульный тест.
  2. Приемочные испытания.
  3. Функциональный тест.

При желании вы можете добавить любой другой пакет по вашему выбору, поэтому здесь мы добавим набор API.

4. Тест API.

1. Модульные тесты

Тестирование наименьшей единицы функциональности, обычно функции/метода. Модульные тесты должны быть сосредоточены на тестировании конкретной функции, например, тестирование метода pop при пустом стеке должно вызывать исключение.

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

Класс Unit имеет предопределенные функции __before и _after , вы можете использовать их для создания объекта перед каждым тестом и последующего уничтожения.

В приведенном выше примере мы создали класс User и сделали функцию для проверки длины пароля, если длина меньше 4 символов, возвращается false, в противном случае возвращается true.

Затем мы создали модульный тест для класса паролей, в этом тестовом классе у нас есть две тестовые функции, поэтому мы можем проверить каждую строку из validLength из класса пароля.

2. Приемочный тест

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

Мы можем выполнить это тестирование с помощью phpBrowser или реального браузера с помощью веб-драйвера Selenium. Но у нас также есть некоторые недостатки для phpBrowser:

  • Вы нажимаете только действительные ссылки
  • Вы не можете заполнять внешние поля формы.

3. Функциональное тестирование

Функциональное тестирование почти такое же, как приемочное тестирование, за исключением того, что для запуска тестов не требуется браузер. Он напрямую взаимодействует с вашим приложением/API и имеет отдельный модуль для php-фреймворков, таких как:

  • Symfony2
  • Laravel5
  • Yii2
  • Zend Framework
Поддерживаемые фреймворки codeception

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

Функциональные тесты — это проверочная деятельность, чтобы ответить на вопрос: «Создали ли мы правильно работающий продукт?», тогда как приемочные тесты — это своего рода проверочная деятельность, чтобы убедиться, что мы создали правильную вещь.

Примечание : Если вы не используете фреймворк, вы не можете писать функциональные тесты, потому что они просто поддерживаются самим фреймворком. Проверьте пример:

4. Тесты API

В Codeception есть возможность создавать собственные наборы, поэтому мы можем создать набор API с помощью команды, предоставленной Codeception.

 vendor/bin/codecept generate:suite api

Приведенная выше команда создаст новую папку с именем tests/api . Каждый набор будет иметь свой собственный файл конфигурации. Откройте api.suite.yml и добавьте необходимую информацию. ваш файл должен выглядеть так:

  • Если вы используете Laravel , вы можете добавить модуль Laravel вместо phpBrowser .

Вот пример теста API:

Вы можете скачать исходный код с примерами набора отсюда.

Установка Codeception?

Мы можем установить Codeception из composer:

 composer require codeception/codeception — dev

После этого запустите следующую команду, которая создаст /tests в вашем проекте.

 /vendor/bin/codecept bootstrap

Конфигурация Codeception

У нас будет codeception.yml в нашем корневом каталоге, который создается с помощью вышеупомянутой команды. Давайте посмотрим на файл codeception.yml , и я также добавил несколько комментариев для описания каждой строки:

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

Структура каталога Codeception

Если вы зайдете в каталог /tests , созданный в результате выполнения команды

./vendor/bin/codecept bootstrap . Там вы увидите следующую структуру каталогов:

Каталог Структура папки тестов
  • _data
    В этом каталоге может быть DB /file/Fixtures , если вам это нужно.
  • _output
    Этот каталог содержит выходные данные тестов в случае неудачи.
  • _support
    В этом каталоге могут быть помощники, если вы напишете их для поддержки своих тестов.
  • приемка
    Этот каталог полезен, если вам нужно написать приемочные тесты.
  • API
    Этот каталог полезен, если вы пишете тесты API. Этот каталог отсутствует по умолчанию, но он будет создан в результате команды создания пакета API.
  • функциональный
    Этот каталог полезен, если вам нужно написать функциональные тесты.
  • модуль
    Этот каталог полезен, если вам нужно написать модульные тесты.
  • _bootstrap.php
    Этот файл полезен для автоматической загрузки любого файла, который вы хотите включить.

    No related posts.