Ответы пользователя по тегу Модульное тестирование
  • Какие еще преимущества у юнит-тестов, кроме того, что они отлично обеспечивают регрессионное тестирование?

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

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

    Но да, с тем, что автотестами нужно покрывать не всё, я лично полностью согласен. Вдобавок, часто высокоуровневые функциональные или end-to-end тесты писать проще, а для проекта они полезнее. Тут надо искать баланс для себя. И еще в это уравнение добавить ручное тестирование. Какой-то общей формулы, понятно, нет.

    А вопрос-то ваш в чём? Пока выглядит как «вы тут меня поуговаривайте писать тесты, а я вам буду объяснять, почему не буду этого делать». Не хотите — не пишите. Если для вашего проекта и для вашей команды тесты не несут большой пользы, то и не пишите их.
    Судя по вашим прошлым вопросам, вы считаете, что всё знаете лучше других, соответственно, вопрос нужен, чтобы потешить ЧСВ? Ну или вы нарвались на какой-то карго-культ-секты-стопроцентного-кавереджа? В таком случае — сочувствую.
    Ответ написан
  • UNITtest можно ли ..?

    alexey-m-ukolov
    @alexey-m-ukolov Куратор тега PHP
    Естественно, при изменении кода нужно менять и тесты.
    Ответ написан
  • Как сделать ошибки в тестах более информативными?

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

    В случае авторизации, например, можно сначала проверить, что пользователь был авторизован, а потом, что произошёл редирект. Тогда можно будет сразу сказать в случае ошибки редиректа - авторизация работает, а вот перенаправление сломалось.

    А ещё, тестовые фреймворки обычно принимают текстовое описание ошибки, чтобы программист мог на понятном ему языке описать возникшую проблему и добавить какие-то детали: данные текущей итерации, текст ответа, ошибки в сессии и т.п.
    Ответ написан
  • В чем суть автотестов с PHPUnit на примере формы?

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

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

    Кроме того, если писать сначала тесты, а потом код, будет улучшаться архитектура (в теории, разумеется). Покрывать тестами код с кривой архитектурой очень-очень больно, поэтому из чистой лени вы будете стараться следовать всяким SOLID'ам, KISS'ам, YAGNI и прочим акронимам.

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

    Это, что касается тестов в целом. Конкретно пример из вопроса лишён смысла, поскольку а) нет никакого смысла писать свой слой работы с БД, когда есть много готовых удобных и протестированных инструментов и б) то, что вы описали, не юнит-тест (ну или как минимум несколько юнит-тестов).
    Ответ написан