Типичный размер модульных тестов по сравнению с тестовым кодом

Question

Мне любопытно, что является разумным / типичным значением для отношения тестового кода к производственному коду, когда люди делают TDD. Глядя на один компонент, у меня есть 530 строк тестового кода для 130 строк производственного кода. Другой компонент имеет 1000 строк тестового кода для 360 строк производственного кода. Таким образом, модульные тесты требуют примерно в 3–5 раз больше кода. Это для кода Javascript. У меня не очень удобно тестировать код на C #, но я думаю, что для другого проекта я смотрел в 2–3 раза больше тестового кода, чем на производственный код.

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

Я знаю, что строки кода - это слабая метрика, но, поскольку я кодирую в одном и том же стиле как для теста, так и для производства (одинаковый формат пробелов, одинаковое количество комментариев и т. Д.), Значения сравнимы.

Answer 1

Это будет зависеть от того, насколько хорошо все учтено, но, по моему опыту (да, я измерял это в некоторых проектах), я видел соотношение от 2: 1 до 5: 1 (это для проверенного кода курс). Также обратите внимание на страницы ProductionCodeVsUnitTestsRatio и UnitTestToCodeRatio на вики-сайте C2.

Answer 2

Ух ты, эти цифры довольно большие! Я примерно 1: 1, иногда для классов, которые имеют более высокую цикломатическую сложность, это может приблизиться к 2: 1 в пользу модульных тестов LOC, но тогда это вызывает тревожные сигналы, что класс нуждается в рефакторинге.

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

Реорганизуете ли вы свои тесты? переместить любое дублирование настроек и т. д. в отдельные методы?

Вы держите свои модульные тесты простыми, чтобы они утверждали только одну вещь за тест?

а вы чрезмерно тестируете такие вещи, как геттеры / сеттеры?

Answer 3

Я лично использую отношение assert к loc. Для некоторых вещей может потребоваться больше макета и кода настройки для тестирования, чем для других. Я чувствую, что строки теста с X по Y строк кода продукта могут быть не очень полезными. Инструмент покрытия кода, вероятно, лучший способ взглянуть на это. Я обнаружил, что в моих последних двух проектах мой код имеет 1 утверждение на 10 строк производственного кода. Кто-нибудь еще получает подобные значения?

Answer 4

Различные языки и рамки тестирования будут сильно отличаться. Например, BDD-фреймворки намного «DRYer», чем код стиля TestUnit. Кроме того, в нескольких проектах у меня были очень большие наборы данных, передаваемые через несколько строк Java, которые тестировали тысячи строк кода, так что мое соотношение было бы просто ошибочным.

Я только что посмотрел три моих последних проекта (рельсы среднего размера), и код для тестирования был равен 1: 2.3, 1: 1.6 и 1: 1.9 ... так что ваши цифры звучат так, как будто они похожи. (Я только что побежал rake stats - я никогда не смотрел на них раньше.)

В любом случае, предупреждающие знаки о том, что у вас слишком много тестов:

• если вы сделаете одно изменение, несколько тестов пройдут неудачно или только один? Если большое количество тестов не пройдено, вы, вероятно, тестируете одно и то же снова и снова и можете устранить большинство из них.
• код выглядит так, как будто он был скопирован и вставлен. Рефакторинг общего кода.
• тесты слишком медленные
• тесты, которые никогда не подводили

Answer 5

Эти цифры звучат нормально. Самый длинный модульный тест, который я написал, был более 1500 строк, и он протестировал только около 300 строк кода.