Yii 2.0.2
13 января 2015
Выпустили версию 2.0.2, являющуюся патч-релизом и полностью обратно совместимую. В неё вошли около 40 исправлений и мелких улучшений.
13 января 2015
Выпустили версию 2.0.2, являющуюся патч-релизом и полностью обратно совместимую. В неё вошли около 40 исправлений и мелких улучшений.
Комментарии RSS по email OK
Блин, ну ребят. Нет никакого юнит-тестирования в связке с базой данных. И нет никаких разрешений зависимостей в юнит-тестировании. Есть моки и ничего больше, потому что иначе тест начинает зависеть уже не только от тестируемого класса, но и от его зависимостей, и простая любая ошибка в подключении к БД обрушит связанные тесты, и человек, увидевший тридцатку статусов "fail", никогда не догадается, в чем причина. Ничто не мешает подменить хоть сам PDO, лежащий на нижнем уровне, и убедиться, что уходящие запросы верны (но, конечно, этого делать не стоит в вышеприведенном примере - там нужно мокать значительно выше). Да, приложение должно тестироваться в связке с реальной БД. Но именно приложение целиком, а, значит, это уже системный уровень, где юнит-тестированием и пробросом конкретных объектов и не пахло (разве что глобальной заменой сервисов на моки, например, внешних апи).
@Etki, мне кажется, что нужен отдельный цикл статей — тестирование для пхпшника, потому что у многих как раз таки юнит тестирование в связке с БД делается. Тоже так раньше делал, молод и глуп был.
С другой стороны можно не усложнять. Признаюсь, грешу, тесты юзают свою тестовую базу с тестовыми данными, может они и не unit в каноническом понимании - ну и хрен с ними.
Если тестовая база отвалится - то будет конкретное сообщение об ошибке "connection refused" и тут только тюлень не поймет в чем проблема. Можно заменить использование всей базы на моки - да будет все как по книжке, но в итоге я бы эти тесты год наверное писал.
Etki, да, это не очень честный юнит, конечно :) Но как ни назови, такие тесты тоже нужны.
@Serge Bezborodov, если вы рассматриваете ситуацию с провалами тестов как бытовую, то это не очень коррелирует с подходом тестирования вообще. @Костя я эту штуку начинал еще в сентябре, но примерно с тех пор работы и личных проблем столько, что непонятно, в каком году к ней вернусь: https://github.com/etki/yii-testing-playground/tree/master/guide/ru я с тех пор поменял взгляды по части вещей, впрочем (и вообще не помню, что там написано).
когда я уже научусь штырить по два пробела в конце абзаца (
@Etki в смысле провалы тестов? отваливание базы - нет, разумеется, такое ну крайне редко бывает а fail непосредственно тестов - вполне бытовая, что то написал новое, что то сломал старое - для этого тесты и есть
наблюдаю как тестирование превращается в тестирование ради тестирования. особенно забавно количество наследований от PHPUnit в итоговом MyTestCase. Это наверно круто.. повышает качество тестов и стресоусточивость!
В решениях по фреймворку как таковые юниты не нужны, только в случаях расширения функционала базового класса. а все остальное должно уже было быть протестировано командой Yii. Потому нужно стартовать их тесты как доп. пакет время от времени. что-то править и т.д.
как правило нужны тесты кот. проверяют готовый ответ (acceptance). И т.н. functional тесты, интеграционные или как там по-крутому это еще можно назвать. Суть не меняется - тестирование максимально с данными, но до генерации текста, то есть, в обьектах. С использованием макетов из массивов, заглушек и т.д. или загрузки дампов. Суть не меняется. Меняется только время на написание самих данных для тестов и их изменение. Если с дампом стартовать быстрее, то редактировать тяжелее.
По поводу 30 ошибок. Моки (или mockup, или в переводе макет) никаким образом тут не при чем. макет может брать данные из базы тоже, не обезательно из файла. может не быть файла - все те же 30 ошибок будет. Что в нужно делать как макет - это разве что сам класс приложения, чтобы сбрасывать его состояние на каждом тесте. И все.
п.с. боролся с codeception последнее время. не понятна идея его принудительного использования в скелете. Но к счастью, все довольно просто переводится на обычный PHPUnit. разве что для acceptance тестирования немного проще, но и сами могли б guzzle прицепить. а так имеем практически ненужный "фарш" PHPUnit -> codeception -> codepection modules -> yii2 test extension -> пишем тесты в котором теряется масса нужной информации для отладки и появляется масса ошибок самих расширений.