Модульное тестирование поведения Yii2 с помощью Codeception

[Ekstazi]

Спасибо.

[Beowulfenator]

Рад стараться!

[Fesor]

Когда смотришь на то, что ты написал сам, сложно представить себе, где оно может сломаться. Мне кажется, что здесь бы помог взгляд со стороны.

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

И да, то что вы называете «модульным тестированием» я называю «интеграционными тестами».

[Beowulfenator]

Я думаю, что до TDD я пока еще не дорос психологически. Что касается терминологии, то в codeception я увидел название unit testing, посмотрел в словаре — вроде это переводится как модульное или блочное тестирование.

[Fesor]

Я не спорю что это так называется, но модульное тестирование подразумевает тестирование одного модуля. А у вас тут имитируется реквест, прогоняется через сервер, есть взаимодействие с данными… Вы тестируете целый кусок системы в сборе. Это еще не функциональные/системные тесты, но уже и не модульные. Да и использовать codeception именно для unit тестирования как-то не удобно. Самое удобное пожалуй для этого — PhpSpec.

Что до TDD — ну до тестов то вы доросли. TDD лишь поможет вам:
— более грамотно проектировать систему (если тесты писать сложно — значит что-то не так с архитектурой приложения)
— писать тесты всегда. Не обязательно добиваться 100% покрытия кода тестами — просто покрыть интерфейс класса тестами и норм, а далее — есть баг или регрессия — пишем тест и потом фиксим.

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

[Davert]

Спор до хрипоты о терминологии в тестирвоании — можно отнести к разряду профессионального заболевания )

[Davert]

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

Дождитесь пока сломается. Напишите тест. Больше там не сломается )
А писать кучу гипотетических тестов в вакуме может действительно не стоит…
Можно, конечно, заморочиться и пройтись по всем классам эквивалентности и покрыть весь код модуля, но всему есть свой разумный предел.

[Beowulfenator]

Дождитесь пока сломается. Напишите тест. Больше там не сломается )

Наверное как-то так оно и получится в итоге.

[Igreh]

Возможно, кому-нибудь пригодится: Codeception. Debug тестов в PhpStorm

[mnv]

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

[Beowulfenator]

Я где-то видел еще вариант с укладыванием файловой базы sqlite в память, чтобы быстрее работало, но для первого раза решил не заморачиваться. Но за идею с транзакциями — спасибо.

[Lebnik]

Ребята, если вам нужны только unit-тесты, то мой вам совет: не используйте Codeception, т.к. он сильно ограничивает phpunit и как пример: вы просто не сможете воспользоваться phpunit.xml настройками, который описаны в документации к phpunit, еще пример: Codeception использует свой хендлер ошибок, полностью перекрывая PHPUnit_Util_ErrorHandler::handleError, и кроме как хака перекрывающего хендлер обратно, это Вы никак не решите. И таких случаев очень много. В настоящий момент, когда у меня в проекте уже естьCodeception, я не понимаю, зачем Codeception мне нужен для unit-тестов, и найти список плюсов, я увы нигде найти не смог.