<rmcreative>

RSS

Yii 2.0.2

13 января 2015

Выпустили версию 2.0.2, являющуюся патч-релизом и полностью обратно совместимую. В неё вошли около 40 исправлений и мелких улучшений.

Полный анонс читайте на хабре

Комментарии RSS

  1. №9559
    Etki
    Etki 13.01.2015, 8:02:14

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

    (создание подключения к БД)

    Блин, ну ребят. Нет никакого юнит-тестирования в связке с базой данных. И нет никаких разрешений зависимостей в юнит-тестировании. Есть моки и ничего больше, потому что иначе тест начинает зависеть уже не только от тестируемого класса, но и от его зависимостей, и простая любая ошибка в подключении к БД обрушит связанные тесты, и человек, увидевший тридцатку статусов "fail", никогда не догадается, в чем причина. Ничто не мешает подменить хоть сам PDO, лежащий на нижнем уровне, и убедиться, что уходящие запросы верны (но, конечно, этого делать не стоит в вышеприведенном примере - там нужно мокать значительно выше). Да, приложение должно тестироваться в связке с реальной БД. Но именно приложение целиком, а, значит, это уже системный уровень, где юнит-тестированием и пробросом конкретных объектов и не пахло (разве что глобальной заменой сервисов на моки, например, внешних апи).

  2. №9561
    Костя
    Костя 13.01.2015, 9:24:31

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

  3. №9563
    Serge Bezborodov
    Serge Bezborodov 13.01.2015, 12:24:15

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

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

  4. №9575
    Sam
    Sam 14.01.2015, 18:21:48

    Etki, да, это не очень честный юнит, конечно :) Но как ни назови, такие тесты тоже нужны.

  5. №9578
    Etki
    Etki 14.01.2015, 23:58:46

    @Serge Bezborodov, если вы рассматриваете ситуацию с провалами тестов как бытовую, то это не очень коррелирует с подходом тестирования вообще. @Костя я эту штуку начинал еще в сентябре, но примерно с тех пор работы и личных проблем столько, что непонятно, в каком году к ней вернусь: https://github.com/etki/yii-testing-playground/tree/master/guide/ru я с тех пор поменял взгляды по части вещей, впрочем (и вообще не помню, что там написано).

  6. №9579
    Etki
    Etki 14.01.2015, 23:59:22

    когда я уже научусь штырить по два пробела в конце абзаца (

  7. №9580
    Serge Bezborodov
    Serge Bezborodov 15.01.2015, 0:01:54

    @Etki в смысле провалы тестов? отваливание базы - нет, разумеется, такое ну крайне редко бывает а fail непосредственно тестов - вполне бытовая, что то написал новое, что то сломал старое - для этого тесты и есть

  8. №9593
    йцукен
    йцукен 27.01.2015, 20:40:28

    наблюдаю как тестирование превращается в тестирование ради тестирования. особенно забавно количество наследований от PHPUnit в итоговом MyTestCase. Это наверно круто.. повышает качество тестов и стресоусточивость!

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

    как правило нужны тесты кот. проверяют готовый ответ (acceptance). И т.н. functional тесты, интеграционные или как там по-крутому это еще можно назвать. Суть не меняется - тестирование максимально с данными, но до генерации текста, то есть, в обьектах. С использованием макетов из массивов, заглушек и т.д. или загрузки дампов. Суть не меняется. Меняется только время на написание самих данных для тестов и их изменение. Если с дампом стартовать быстрее, то редактировать тяжелее.

    По поводу 30 ошибок. Моки (или mockup, или в переводе макет) никаким образом тут не при чем. макет может брать данные из базы тоже, не обезательно из файла. может не быть файла - все те же 30 ошибок будет. Что в нужно делать как макет - это разве что сам класс приложения, чтобы сбрасывать его состояние на каждом тесте. И все.

    п.с. боролся с codeception последнее время. не понятна идея его принудительного использования в скелете. Но к счастью, все довольно просто переводится на обычный PHPUnit. разве что для acceptance тестирования немного проще, но и сами могли б guzzle прицепить. а так имеем практически ненужный "фарш" PHPUnit -> codeception -> codepection modules -> yii2 test extension -> пишем тесты в котором теряется масса нужной информации для отладки и появляется масса ошибок самих расширений.

  1. Почта опубликована не будет.

  2. Можно использовать синтаксис Markdown или HTML.

  3. Введите ответ в поле. Щёлкните, чтобы получить другую задачу.