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

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

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


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

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

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

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

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

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    TDD

    - пишем тесты - маленький кусочек, то что можно минут за 10 написать. На этом этапе мы формулируем что мы хотим написать.
    - пишем код - пишем код, который делает тесты "зелеными". то есть все работает. Мы делаем это максимально быстро, самым тупым способом, который просто быстрее всего сделать.
    - рефакторинг - после того как все работает, или еще через пару итераций, что бы набралось чуть больше "грязи", чистим код поочередно. Важно при рефакторинге чистить что-то одно. Либо код, либо тесты (да да, их тоже надо рефакторить иногда устраняя дублирование). Поправили код - прогнали тесты, все хорошо? тогда можно тесты подправить. Ну и т.д.

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

    TDD - для одного разработчика, BDD - для команды. А BDD-style assertions для chai - это пафос. По сути это "планирование фич" в рамках библиотек и отдельных объектов. Чуть меньший масштаб. Но ничем от TDD вообще не отличается, хотя если сильно постараться можно так же оценивать ценность фич для пользователей нашей библиотеки и т.д.

    Как никак в BDD основная мысль - фичаспеки должен иметь возможность читать продукт оунер или стэкхолдеры, то есть те кому проект собственно нужен, что бы говорить должно работать так или нет. В случае с библиотеками... ну вы пишите что-то для девелоперов, а они в состоянии читать тесты как фичаспеку. И в принципе от предметной области недалеко.
    Ответ написан
    1 комментарий
  • Какой язык выбрать для автоматизации тестирования?

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

    Я бы рекомендовал вам посмотреть в сторону python или javascript (ruby тоже можно, с капибарой какой, просто python универсальнее).

    Так же немаловажно учитывать на чем написан проект который вы собираетесь покрывать тестами. Если у вас есть люди в команде которые помогут вам с программированием то это несомненнно будет плюсом.
    Ответ написан
    Комментировать
  • Для чего нужен Matcher?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    что бы сравнивать значения, ожидаемое и имеющиеся. Без них никак. А кастомные матчеры - для того что бы устранять дублирование в тестах и упрощать их написание.
    Ответ написан
  • Изучать ли сразу TDD при изучении рельсов?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Вам нужно осознать ценность тестов. Рефакторинг проекта без тестов это боль и слезы. Лучше сразу разобраться в вопросах тестирования кода так как потом заставить себя будет намного сложнее, а скорее всего если проект лично ваш и он проживет больше года, то его придется таки рефакторить и стоимость изменений будет выше либо все со временем превратиться в неподдерживаемое мессиво на кастылях.
    Ответ написан
    Комментировать
  • В чем преимущество phantomjs перед selenium?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    phantomjs - headless-браузер.
    selenium - если упрощать, средство управления браузером посредствам скриптов.

    Следовательно, если у нас есть селениум, то нам нужен браузер. PhantomJS для этого годится, подключаем драйвер нужный и вперед. Если же у нас есть только PhantomJS можно управлять им из API который он предоставляет. Но это не так удобно и всеравно обычно используют отдельные приложения для автоматизации.
    Ответ написан
    Комментировать
  • Требуется тестирование и анализ кода php. Какой аналог есть у phpDocumentor и PHPUnit?

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

    Так же рекомендую посмотреть Behat для функциональных тестов (для BDD).

    Что вы подразумеваете под анализом PHP кода? Есть статические анализаторы, но как я понял вы пытаетесь как-то жить без нормального автокомплита. Может не стоит страдать ерундой а просто воспользоваться IDE? Да и для саблайма есть плагины.
    Ответ написан
  • Как подключить phpDocumentor через composer?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    читаем документацию к composer:
    https://getcomposer.org/doc/

    В частности в пакетах указываются бинарники. По умолчанию они ставятся (а точнее симлинки на них) в vendor/bin, но можно в composer.json попросить ложить их куда-то еще:
    {
        "config": {
            "bin-dir": "bin"
        }
    }
    Ответ написан
  • Разработка через тестирование - как не нарушить инкапсуляцию?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Ну по хорошему мы не должны покрывать тестами приватные методы, только публичные интерфейсы. Но если очень хочется, то любой приватный метод можно сделать публичным в тестах:
    public function invokeMethod(&$object, $methodName, array $parameters = array())
    {
        $reflection = new \ReflectionClass(get_class($object));
        $method = $reflection->getMethod($methodName);
        $method->setAccessible(true);
    
        return $method->invokeArgs($object, $parameters);
    }


    Тема по поводу того хорошо это или плохо частенько обсуждается, иногда по другому никак.
    Ответ написан
    Комментировать