Покрытие кода поблочного тестирования - у Вас есть 100%-е покрытие?

У меня есть 100% покрытие только для новых фрагментов кода, которые были написаны с учетом тестируемости . При правильной инкапсуляции каждый класс и функция могут иметь функциональные модульные тесты, которые одновременно обеспечивают почти 100% покрытие. Затем остается лишь добавить несколько дополнительных тестов, которые охватывают некоторые крайние случаи, чтобы вы смогли достичь 100%.

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

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

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

Да, делаем.

Это зависит от того, на каком языке и в каких рамках вы » Я использую Ruby on Rails для моего текущего проекта. Ruby очень "издевается" в том смысле, что вы можете заглушать / имитировать большие фрагменты кода без необходимости встраивать слишком сложные композиции классов и конструкции конструкции, которые вам пришлось бы делать на других языках.

Тем не менее, у нас есть только 100% покрытие линии (в основном то, что дает вам rcov). Вам все равно придется подумать о тестировании всех необходимых ветвей.

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

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

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

Добавляет ли это ценность? Сначала я был настроен скептически, но могу честно сказать, что да. Не в первую очередь потому, что вы тщательно протестировали код (хотя это определенно является преимуществом), а скорее с точки зрения написания простого кода, который легко проверить и обдумать. Если вы знаете, что у вас есть , чтобы иметь 100% тестовое покрытие,

Я лично считаю, что 100% тестовое покрытие проблематично на нескольких уровнях. Прежде всего, вы должны убедиться, что вы получаете ощутимую экономию средств от написанных вами модульных тестов. Кроме того, модульные тесты, как и любой другой код, являются КОДОМ. Это означает, что его, как и любой другой код, необходимо проверять на правильность и поддерживать. Это дополнительное время на проверку дополни- тельного кода на правильность, а также на его поддержку и поддержание этих тестов в силе в ответ на изменения в бизнес-коде увеличивает затраты. Достижение 100% покрытия тестами и обеспечение максимально тщательного тестирования кода - это похвальное усилие, но его достижение любой ценой ... ну, часто бывает слишком дорого.

Существует много случаев, когда при покрытии ошибок и проверок достоверности используются незначительные или крайне редкие, но определенно возможны, исключительные случаи - это пример кода, который не обязательно должен быть описан. Количество времени , усилий (и, в конечном счете, денег ), которое необходимо инвестировать для покрытия таких редких второстепенных случаев, часто расточительно в свете других потребностей бизнеса. Свойства часто являются частью кода, который, особенно в C # 3.0, не нужно тестировать, поскольку большинство, если не все, свойства ведут себя точно так же и чрезмерно просты (возврат или установка с помощью одного оператора). Вложение огромных сумм. Обертывание по времени модульных тестов вокруг тысяч объектов, скорее всего, лучше вложить в другое место, где можно получить более значительную и более ценную ощутимую отдачу от этих инвестиций.

Помимо простого достижения 100% покрытия тестами, Аналогичные проблемы возникают при попытке настроить «идеальный» блок. Фреймворки имитации в наши дни достигли поразительного прогресса, и почти все можно высмеять (если вы готовы платить деньги, TypeMock фактически может имитировать все и вся, но это стоит дорого). Однако часто бывают случаи, когда зависимости вашего кода не были написаны имитирующим образом (на самом деле это основная проблема огромной части самой платформы .NET). Полезно потратить время на достижение надлежащего объема теста, но добавление чрезмерного количества время поиздеваться над всем и вся, что скрывается под солнцем, добавляя уровни абстракции и интерфейсов, чтобы сделать это возможным, опять же, чаще всего, является пустой тратой времени, усилий и, в конечном итоге, денег.

Конечная цель тестирования - не " Это действительно для достижения максимального покрытия кода. Конечная цель должна заключаться в достижении максимальной отдачи от единицы времени, затраченной на написание модульных тестов, при одновременном покрытии как можно большего количества времени. Лучший способ добиться этого - использовать подход BDD: указать свои проблемы, определить свой контекст и убедиться, что ожидаемые результаты возникают для любой разрабатываемой части поведения (поведения ... не единицы.)

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

Инструмент автоматического тестирования, такой как Pex , может помочь увеличить покрытие кода. Он работает путем поиска крайних случаев, которые трудно найти.

Нет, потому что существует практический компромисс между идеальным модульным тестированием и фактическим завершением проекта :)

Обычно мне удается набрать 93 .. 100% с моим покрытием, но я больше не стремлюсь к 100%. Я делал это раньше, и хотя это выполнимо, это не стоит усилий сверх определенного момента, потому что слепо очевидное тестирование обычно не требуется. Хорошим примером этого может быть истинная оценочная ветвь следующего фрагмента кода

public void method(boolean someBoolean) {
    if (someBoolean) {
        return;
    } else {
        /* do lots of stuff */ 
    }
}

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

Да, у меня были проекты со 100% охватом линий. См. Мой ответ на аналогичный вопрос.

Вы можете получить 100% покрытие линии , но, как указывали другие здесь на SO и в других местах в Интернете, возможно только минимум. Когда вы рассматриваете покрытие путей и ветвей, вам предстоит еще много работы.

Другой способ взглянуть на это - попытаться сделать ваш код настолько простым, чтобы легко было получить 100% покрытие строк.

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

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

Поскольку это было в VC6 (C ++ + MFC), я определил два макроса:

#define TCOV ASSERT(FALSE)
#define _COV ASSERT(TRUE)

и затем добавил

TCOV;

во всем коде, на каждом отдельном пути, который я мог найти, и в каждой программе. Затем я запускал программу под отладчиком, и каждый раз, когда она попадала в TCOV , она останавливалась. Я бы посмотрел на код на предмет очевидных проблем, затем отредактировал его на _COV и продолжил. Код будет перекомпилирован на лету и перейдет к следующему TCOV . Таким образом, я медленно и кропотливо удалил достаточно операторов TCOV , чтобы он работал «нормально».

Через некоторое время я нашел код для TCOV , и это показало какой код я не тестировал. Затем я вернулся и снова запустил его, убедившись, что протестировал больше веток, которые я не пробовал раньше. Я продолжал это делать, пока в коде не осталось операторов TCOV .

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

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

From Ted Neward blog.

By this point in time, most developers have at least heard of, if not considered adoption of, the Masochistic Testing meme. Fellow NFJS'ers Stuart Halloway and Justin Gehtland have founded a consultancy firm, Relevance, that sets a high bar as a corporate cultural standard: 100% test coverage of their code.

Neal Ford has reported that ThoughtWorks makes similar statements, though it's my understanding that clients sometimes put accidental obstacles in their way of achieving said goal. It's ambitious, but as the ancient American Indian proverb is said to state,

If you aim your arrow at the sun, it will fly higher and farther than if you aim it at the ground.