TDD и покрытие кода

Question

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

Является ли покрытие кода задним числом? Ваш процесс идет как-то вроде

1. Написать тест для функциональности, которая будет реализована
2. Запустите тест, убедитесь, что они не прошли
3. Реализация функциональности
4. Запустите тест, убедитесь, что они прошли
5. Напишите больше тестов на функциональность, пока не будет получено 100% (или почти) покрытие кода

Или вы запускаете покрытие кода в самом конце после того, как были реализованы многочисленные функциональные части, а затем возвращаетесь и работаете для достижения 100% покрытия?

Третий вариант, о котором я могу подумать, - стремиться к 100% охвату, даже не реализовав функциональность.

Что из этого является наиболее распространенным и каковы преимущества?

Answer 1

Вы не пишете тесты, пока не будет достигнут 100% охват кода. Если вы следили за TDD, то существует код no , который когда-либо был написан без необходимости теста, поэтому вы всегда должны быть на 100% охватом.

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

Answer 2

С TDD вы почти всегда должны быть на 100% покрыты при разработке нового кода, так как вы не разрабатываете код, который вам не нужно проходить тесты.Только когда вы думаете, что код настолько прост, что вам не нужен тест (скажем, как автоматическое свойство в C #), у вас должен быть код, который специально не рассматривается.С помощью рефакторинга вы можете иногда вводить ненужные блоки или неожиданно изменять код, поэтому вы можете захотеть использовать покрытие в этот момент, чтобы убедиться, что вы случайно не ввели непроверенный код.Кроме этого, я бы сказал, что я использую его больше как проверку работоспособности и периодически делаю анализ покрытия по тем же причинам.Это также может быть очень полезно, когда ваша дисциплина нарушается, и вы пренебрегаете работой TDD.

Answer 3

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

Тест записи: сбой Написать код: Pass Refactor: Pass

Перейти наверх