Как измерить покрытие кода в веб-приложении с помощью модульных и функциональных тестов

Question

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

Я реализовал несколько юнит-тестов, используя jest + энзим. также некоторый функциональный тест, использующий огурец, чтобы получить функции корнишона и кукловод для автоматизации браузера.

Я смог получить покрытие из кода, созданного веб-пакетом и предоставленного на моем локальном хосте, используя кукловод и Стамбул через функциональные тесты. Кроме того, я получаю покрытие кода в модульном тесте с использованием jest (кстати, для этого в него включен istanbul).

Проблема в том, что я чувствую, что это две разные метрики, потому что я тестирую компоненты с помощью jest + энзимный файл за файлом, а с другой стороны, у меня есть покрытие кода от кукловода, которое на самом деле представляет собой единый встроенный js-файл.

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

Итак, мои вопросы:

• имеет смысл измерять покрытие кода на модульных и функциональных тестах?

• имеет смысл объединять покрытие кода из юнит-тестов и функциональных тестов? а если есть смысл как это сделать?

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

Answer 1

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

Я бы начал с вопроса, почему мы измеряем покрытие кода? И.Е. Каковы изменения в том, как работает команда, которую вы пытаетесь создать? Я вернусь к этому вопросу, отвечая на ваши конкретные вопросы.

На данный момент стоит убедиться, что покрытие кода будет стимулировать поведение, которое вы ищете. Подробнее об этом смотрите на этой бумаге . Я пытался решить этот вопрос в недавнем сообщении в блоге .

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

measure the code coverage on unit tests and functional tests?

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

merge code coverage from unit tests and functional tests?

Давайте рассмотрим пример, в котором вы хотите побудить разработчиков написать больше юнит-тестов. В этом случае, я бы сказал, нет, не объединять освещение. Желаемое изменение поведения заключается в том, что разработчики должны писать больше тестов, поэтому вы не хотите маскировать их отсутствие тестирования, сообщая о метрике, которая включает функциональные тесты от команды QA.

Однако, если вы рассматриваете группу разработки программного обеспечения и хотели бы провести больше тестов от всей группы (разработчиков и QA), то просто объедините цифры покрытия и сообщите общее покрытие.

if has sense how to do that?

Существует множество инструментов, которые позволят вам объединить информацию о покрытии из нескольких прогонов. Один из моих любимых (если вы можете использовать облачные сервисы) - CodeCov . Это отличный способ визуализации покрытия кода с минимальными усилиями по установке.

what is the best approach to get code coverage from a webapp?

Я оставлю это для кого-то, кто понимает более подробно, чем я, технологии, которые вы используете.