Цели покрытия полезного / реалистичного кода для приложения ASP.NET для «коричневого поля»

Question

Позвольте мне уточнить этот вопрос. Я работаю над «классическим» приложением ASP.NET (веб-формы), которое не использует Model-View-Presenter и не было написано с использованием TDD. Он также использует устаревшую стратегию доступа к данным (рукописный слой DAO, который вызывает хранимые процедуры для заполнения и сохранения объектов), который вряд ли будет обновлен до ORM, несмотря на мое сильное желание сделать это.

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

Код бизнес-логики явно включен, но как насчет кода WebForms? Кроме того, как насчет кода доступа к данным? Как упоминалось выше, наш уровень доступа к данным использует хранимые процедуры для заполнения графов объектов и сохранения их обратно в БД. Является ли постоянство объекта и регидратация чем-то, что должно быть включено?

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

Спасибо!

Answer 1

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

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

В качестве параллельного примера вы не поверите, сколько комментариев кода «Keep FxCopy happy» я видел в своей карьере.

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

И наоборот, разработчики, которые понимают преимущества TDD, не нуждаются в цели, потому что они будут делать правильные вещи, независимо от того.

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

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

Answer 2

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

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

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

Answer 3

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

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

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