Ответы пользователя по тегу PHPUnit
  • Как правильно написать unit тест?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1) это не юнит тест, это интеграционный тест. Он проверят "часть системы в сборе", в вашем случае апишку. Если бы вы тестировали через UI (то есть через ангуляр) - это называлось бы end-to-end тест (от кнопок до базы данных мол).

    2)
    На просторах инета вижу простые примеры тестов которые проверяют на true false


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

    Что вам по сути важно когда вы пишите апишку? Скорее всего вы хотите всегда знать что структура ваших ответов не сломалась. Что вы случайно не поменяли имя поля, или случайно не убрали нужные поля. Для этого есть такая штука как json schema. То есть мы берем json и проверяем на соответствие. Опять же для phpunit можно найти готовые ассерты что бы не пилить велосипед.

    Далее, что еще нам может хотеться проверить - статус коды. Это опять же легко и думаю в документации к laravel это есть. Так же возможно вы захотите проверять заголовки но это уже специфичные штуки.

    Словом все что вы хотите проверить - вы просто проверяете. Правильно - это когда оно выполняет ваши потребности.

    Ну и возможно вам захочется проверить данные в json ответе. Тут уже есть кучи вариантов. Я например запилил свой велосипед для частичного сравнения JSON-а (ну не интересно мне все проверять). Можно и другими решениями это делать, но лично я такие штуки на этом уровне проверяю крайне редко, ибо... ну у меня другие тесты за проверку логики отвечают.
    Ответ написан
  • Можно ли задать ожидание порядка выполнения методов мока в phpunit?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    и нужно ли это делать в юнит-тестах?


    не нужно, поскольку вы таким образом жестко привязываете себя к текущей реализации. Чем меньше ваши тесты знают о тестируемом коде - тем лучше. В целом примите за правило что мокать нужно либо интерфейсы (причем ваши желательно, инверсия зависимости и все такое), либо то что общается с внешним миром. Все остальное желательно не мокать что бы не завязывать тесты на имплементацию.
    Ответ написан
  • Зачем тестировать код?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Что тут тестировать и зачем? в случае неудачи получим исключение. Названия колонок мы знаем. Данные в контроллере валидируются.


    вы должны проверять корректность работы системы. Всего-то. Причем с оглядкой не только на "сейчас" (тут мы и руками можем проверить быстро) но еще с оглядкой на будущее. Если вы планируете этот код выкинуть - тестировать его нет смысла. Вы на автоматизацию тестирования убьете больше времени чем проверите руками.

    С другой стороны, если это лишь вершина айсберга, то имеет смысл написать простенький автотестик, который проверяет корректность работы. Так, если мы будем вносить какие-то изменения, например будем добавлять комменты, мы будем уверены на 90% что ничего не сломали. Почему не на 100%? потому что невозможно покрыть все тестовые сценарии да и это не выгодно. Проверяем мы обычно самые вероятные сценарии.

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

    Но такой тест отрабатывает относительно долго. Представьте себе что вы пишите что-то посложнее. И у вас уже 100 различных тестовых сценариев для одого кусочка системы. В итоге этот маленький кусочек будет тестироваться больше минуты, и мы успеем заскучать. Для того что бы упростить - мы дробим этот кусочек еще и еще пока не находятся такие куски, которые мы можем проверить удобно и быстро. Например если вопрос в корректности валидации данных - мы можем тестировать только контроллер, а если вопрос в каких-то бизнес правилах отдельных - мы можем и их отдельно вынести и тестировать. Это будут интеграционные тесты.

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

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

    По сути это самое сложное в тестировании. Писать тестируемый и поддерживаемый код, а так же останавливать себя от тестирования "лишних" частей системы или слишком углубляться в тестирование там где этого не нужно.
    Ответ написан
  • В Yii2 для написания тестов использовать codeception или phpunit?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    codeception для интеграционных тестов, phpunit для любых функциональных тестов.

    Используйте то что вам удобно.
    Ответ написан
  • Как писать кошерные юнит тесты в symfony2 когда вся логика в контроллерах?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    юнит тесты - это тесты которые тестируют юниты (то есть подразумевается хоть какая-то степень изоляции, от полной (когда все замокано) до не очень полной (если мокать все не сильно удобно)).

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

    По вашим пунктам - делайте так, как вам удобно. Ну то есть суть всего сводится к тому что бы с кодом вашего приложения было удобно работать. Тесты это способ упрощения внесения изменений в код. Если вам из-за тестов не удобно - надо придумать как сделать так что бы было удобно (либо у вас что-то не так с тестами либо с кодом, раз его не удобно тестить).
    Ответ написан
  • Как вы пишите тестируемый код?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    соответственно при тестировании необходимо обернуть его в Mock

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

    Писать в каждой модели конструктор?

    Что вы понимаете под "модель"? Ваши бизнес-объекты? У них в конструкторе должно быть только то, что им нужно.

    а если источников будет много

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

    User::model()->prepareBuy(new Order, New Profile, $userId)


    Прочитайте эту строчку кода, и скажите что тут происходит, ибо я не могу этого понять.

    Ну и да, помимо внедрения зависимостей в конструктор, есть еще такая неплохая штука как double dispatch, когда нужные сервисы передаются как аргументы методов, которым они нужны. Так наш класс не зависит от непонятных вещей и таким образом мы все можем спокойно тестить.
    Ответ написан
  • Как вы тестируете статические методы?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Как вы тестируете статические методы?


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

    В вашем же вопросе вы интересуетесь как мокать статические методы. И тут ответ тоже никак:
    Please note that final, private and static methods cannot be stubbed or mocked. They are ignored by PHPUnit's test double functionality and retain their original behavior.


    Есть правда еще мокери всякие и т.д.
    Ответ написан
  • Symfony2 ajax qjuery и юнит тест?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Selenium и тестирование в хроме/фаерфоксе/phantomjs
    Ответ написан
  • Как сделать чтобы тесты проекта на Symfony2 запускались в NetBeans?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1) не используйте phpunit глобально, ставьте его как dev зависимость через composer. Это как минимум удобно.

    2) проверьте пути до файла конфигурации. Что-то мне подсказывает что нужно писать phpunit -c app. Либо же у вас проект содержит все имеющиеся домены что несколько странно.

    3) для собственного удобства можно вынести phpunit.xml.dist в корень проекта, для этого нужно будет только чуточку поправить пути в нем же.
    Ответ написан
  • Yii 1.1 и PHPUnit 4.0.14 - почему не выполняются тесты?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Потому что не нужно для phpunit что-то подключать. Используйте composer, и сам phpunit как dev зависимость укажите. Просто подключите автолоадер composer-а после yii-шного и все будет работать.
    Если же вы используете phar версию, то темболее вроде как ничего инклудить не нужно. Но тут не берусь говорить.
    Ответ написан
  • Phpunit - как это тестировать?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    вы не можете использовать mock так как у вас инстанцирование класса MainLogger происходит прямо в функции endApp(). Что бы это обойти, передавайте MainLogger в конструктор класса содержащего этот метод, и в тестах просто подменяйте на мок.

    По поводу exit - тут только если тестами уровня приложения тестить, юнит тесты такое не покрывают. Ну и опять же делать exit внутри какого-то метода не так уж и хорошо.

    Либо же приведенный вами код не раскрывает что у вас и как, ибо описание с кодом расходится. Почитайте вообще про S.O.L.I.D. и в частности про Dependency Inversion.
    Ответ написан
  • Как правильно покрывать код тестами?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Дублирование кода в тестах нужно устранять. Почитайте XP Programming Кента Бэка, он там затрагивал вопрос касательно рефакторига тестов, как часто его нужно делать и т.д.

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