Типичный размер модульных тестов по сравнению с тестовым кодом
Мне любопытно, что разумное / типичное значение для отношения тестового кода к производственному коду, когда люди делают TDD. Смотря на один компонент, у меня есть 530 строк тестового кода для 130 строк производственного кода. Другой компонент имеет 1 000 строк тестового кода для 360 строк производственного кода. Таким образом, модульные тесты требуют примерно 3x к 5x столько же кода. Это для кода JavaScript. У меня нет многого, протестировал удобный код C#, но я думаю для другого проекта, я смотрел на 2x к 3x столько же тестового кода затем производственный код.
Мне казалось бы, что ниже, что значение, принимая тесты, достаточны, отразил бы более высокие качественные тесты. Чистое предположение, я просто задаюсь вопросом, какие отношения другие люди видят.
Я знаю, что строки кода являются свободной метрикой, но так как я кодирую в том же стиле и для теста и для производства (тот же формат интервала, та же сумма комментариев, и т.д.), значения сопоставимы.
4 ответа
Ого, эти цифры довольно большие! Я примерно 1: 1, иногда для классов с более высокой цикломатической сложностью он может приближаться к 2: 1 в пользу модульных тестов LOC, но тогда это вызывает тревогу, что класс нуждается в рефакторинге.
Вы упомянули, что используете тот же стиль для своих модульных тестов. Это хорошо, если рассматривать ваши тесты как производственный код, но действительно ли вам нужно много комментариев для тестового кода? Вы называете свои методы тестирования так, чтобы они описывали то, что утверждает тест? например, используя имя функции «GivenXWhenYThenZ», тогда должно быть довольно ясно, что делает тест без большого раздела комментариев.
Вы проводите рефакторинг своих тестов? переносить любое дублирование настройки и т. д. в отдельные методы?
Сохраняете ли вы свои модульные тесты простыми, чтобы они утверждали только одну вещь за тест?
и вы чрезмерно тестируете такие вещи, как геттеры / сеттеры?
Это действительно будет зависеть от того, насколько хорошо все учтено, но, по моему опыту (да, я измерял это в некоторых проектах), я видел отношения от 2: 1 до 5: 1 (это для проверенный код конечно). Также посмотрите страницы ProductionCodeVsUnitTestsRatio и UnitTestToCodeRatio в вики-странице C2.
Различные языки и среды тестирования будут сильно отличаться. Например, фреймворки BDD намного «СУЖЕЕ», чем код стиля TestUnit. Кроме того, в паре проектов у меня были очень большие наборы данных, передаваемые через несколько строк кода Java, которые проверяли тысячи строк кода, так что мое соотношение было совершенно неуместным.
Я только что посмотрел на свои три последних проекта (рельсы среднего размера), и код для тестирования был соотношением 1: 2,3, 1: 1,6 и 1: 1,9 ... так что цифры кажутся похожими. (Я только что запустил rake stats - я никогда особо не смотрел на них раньше.)
В любом случае, предупреждающие знаки, что у вас слишком много тестов:
- если вы сделаете одно изменение, несколько тестов не пройдут, или всего один? Если большое количество тестов терпит неудачу, вы, вероятно, тестируете одно и то же снова и снова и можете устранить большинство из них. Код
- выглядит так, как будто он был скопирован и вставлен. Выполните рефакторинг общего кода.
- тесты слишком медленные
- тесты, которые ни разу не провалились
Эти числа звучат нормально. Самый длинный модульный тест, который я написал, состоял более чем из 1500 строк, и он проверял только около 300 строк кода .