Является ли тестовый охват адекватной мерой качества кода?

Question

Если у меня есть какой -то код, который имеет 80% тестового покрытия (все тесты проходят), справедливо ли сказать, что он более высокий качество, чем код без тестового покрытия?

Или справедливо сказать, что это более поддерживается?

Answer 1

В строгом смысле, несправедливо предъявлять какие -либо претензии, пока не будет установлено качество испытательного набора. Прохождение 100% тестов не имеет смысла, если большинство тестов являются тривиальными или повторяющимися друг с другом.

Вопрос в том: В истории проекта кто -нибудь из этих тестов раскрыл ошибки? Цель теста - найти ошибки. И если они этого не сделали, они потерпели неудачу как тесты. Вместо улучшения качества кода они могут только дать вам ложное чувство безопасности.

Чтобы улучшить ваши тестируемые конструкции, вы можете использовать (1) методы белого ящика, (2) методы Blackbox и (3) тестирование на мутации.

(1) Вот несколько хороших методов белого ящика, которые можно применить к вашим тестовым конструкциям. Тест белого ящика построен с учетом конкретного исходного кода. Одним из важных аспектов тестирования Whitebox является покрытие кода:

• Каждая функция называется? [Функциональное покрытие
• Каждый заявление выполнено? [Охват оператора- как функциональное покрытие, так и охват операторов очень простые, но лучше, чем ничего
• Для каждого решения (например if или же while), у вас есть тест, который заставляет его быть правдой, а другой заставляет его быть ложным? [Покрытие решения
• Для каждого условия, которое является соединением (использует &&) или дизъюнкция (использует ||), у каждой подэкспрессии тест, где она истина/ложь? [Покрытие состояния
• Покрытие петли: у вас есть тест, который заставляет 0 итераций, 1 итерация, 2 итерации?
• Это каждый break Из цикльной петли?

(2) Методы Blackbox используются, когда требования доступны, но сам код не является. Это может привести к высококачественным тестам:

• Ваши тесты Blackbox охватывают несколько целей тестирования? Вы захотите, чтобы ваши тесты были «толстыми»: они не только тестируют функцию X, но и тестируют Y и Z. Взаимодействие различных функций - отличный способ найти ошибки.
• Единственный случай, когда вы не хотите «жирных» тестов, - это когда вы тестируете условие ошибки. Например, тестирование для недопустимого пользовательского ввода. Если вы попытались достичь нескольких недопустимых целей тестирования ввода (например, неверный почтовый индекс и неверный адрес улицы), вероятно, один случай маскирует другой.
• Рассмотрим типы ввода и сформируйте «класс эквивалентности» для типов входов. Например, если ваш код проверяет, чтобы увидеть, является ли треугольник равносторонним, тест, в котором используется треугольник с сторонами (1, 1, 1), вероятно, найдет те же виды ошибок, что и тестовые данные (2, 2, 2) и (3, 3, 3) найдет. Лучше тратить свое время на размышления о других классах ввода. Например, если ваша программа обрабатывает налоги, вам понадобится тест на каждую налоговую минку. [Это называется разделением эквивалентности.
• Особые случаи часто связаны с дефектами. Ваши тестовые данные также должны иметь граничные значения, например, на, выше или ниже края задачи эквивалентности. Например, при тестировании алгоритма сортировки вы захотите проверить с пустым массивом, одним массивом элемента, массивом с двумя элементами, а затем очень большим массивом. Вы должны рассмотреть граничные случаи не только для ввода, но и для вывода. [Это анализ пограничной стоимости вызова.
• Другая техника - «Ошибка угадания». У вас есть чувство, если вы попробуете какую -то особую комбинацию, которую вы можете взять с собой программу? Тогда просто попробуйте! Запомнить: Ваша цель - найти ошибки, а не подтвердить, что программа действительна. Анкет У некоторых людей есть умение угадать ошибку.

(3) Наконец, предположим, что у вас уже есть много хороших тестов для покрытия белого ящика и примененные методы Blackbox. Что еще можно сделать? Пора Проверьте свои тесты. Анкет Одна техника, которую вы можете использовать, - это тестирование мутации.

При тестировании на мутации вы вносите модификацию (копию) вашей программы, в надежде создать ошибку. Может быть мутация:

Изменить ссылку на одну переменную на другую переменную; Вставить функцию ABS (); Менять меньше, чем на большее, чем; Удалить заявление; Заменить переменную на постоянную; Удалить соответствующий метод; Удалить ссылку на супер -метод; Изменить аргумент порядка

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

---

Приложение: Я забыл упомянуть этот эффект: Ошибки, как правило, кластер. Анкет Это означает, что чем больше ошибок вы найдете в одном модуле, тем выше вероятность того, что вы найдете больше ошибок. Таким образом, если у вас есть тест, который не удается (то есть тест успешен, поскольку цель состоит в методы выше.

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

Answer 2

По одному определению это более поддерживается, так как любое нарушающее изменение, скорее всего, будет поймано тестами.

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

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

Answer 3

Код без абсолютно никаких тестов может быть чрезвычайно качественным, читаемым, красивым и эффективным (или общим мусором), поэтому нет, не справедливо сказать, что код с 80 % тестовым покрытием имеет более высокое качество, чем код без тестового покрытия.

Было бы справедливо сказать, что код 80 % покрыта хороший тесты есть вероятно приемлемого качества и вероятно Относительно обслуживание. Но это на самом деле гарантирует мало.

Answer 4

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

Было бы справедливо назвать это более поддерживаемым.

Answer 5

Я бы согласился с обслуживаемой частью. Майкл Фетерс недавно опубликовал видео отличного разговора о его под названием "Глубокая синергия между тестируемостью и хорошим дизайном«В котором он обсуждает эту тему. В разговоре он говорит, что отношения являются одним из способов, то есть кода, который хорошо спроектирован, является тестируемым, но тестируемый код не обязательно хорошо спроектирован.

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

Answer 6

Я уже давно задаю себе этот вопрос в связи с «охватом условий». Так как насчет этой страницы от Atollic.com "Почему анализ покрытия кода?"

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

Это кажется довольно актуальным здесь. Если у вас есть набор тестового примера, который удается достичь определенного уровня (кода или иного) покрытия, то вы, скорее всего, ссылаетесь на тест на код с довольно исчерпывающим набором входных значений! Это не расскажет вам много о тестировании кода (если код не раздувается или генерирует обнаруживаемые недостатки), но дает вам Уверенность в вашем наборе тестовых примеров.

В интересном Некер куб Изменение вида, тестовый код теперь тестируется тестируемым кодом!

Answer 7

Есть много способов гарантировать, что программа делает то, что вы намереваете, и обеспечить, чтобы модификации не будут иметь непреднамеренных последствий.

Тестирование одно. Избегать мутации данных - еще одна. Так же система типа. Или формальная проверка.

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