VB.NET Testing Framework для небольших проектов?

Question

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

Я одинокий разработчик, работающий над проектом в основном в свободное время. Пока я подхожу к 100 классам и начинаю понимать, что тестирование многих классов становится утомительным. Тем более, что я возвращаюсь и добавляю перегрузки операторов для =, <>, CType и Not; орудие IComparable(Of T), IEquatable(Of T), IEqualityComparer(Of T); и переопределяющие базовые методы, такие как Equals и GetHashCode.

Мой текущий метод тестирования состоял в том, чтобы случайным образом набросать некоторый код Debug.Print для определенного класса / метода на фиктивной форме за одной кнопкой, запустить проект, нажать кнопку и убедиться, что в окне отладки есть ожидаемые значения значение. Но это утомительно и начинает терять время.

Что я знаю, что мне нужно сделать для каждого класса, составить набор тестов, специфичных для этого класса, чтобы проверить его функциональность. Поэтому я иду и смотрю на среды тестирования, такие как NUnit, Gallio / MbUnit и т. Д. Но я действительно не вижу в них ценности. До сих пор кажется, что я мог бы просто написать отдельный тестовый класс для каждого реализованного класса, обернутый в #If DEBUG/#End If блоки и связать их с кучей кнопок в большой форме для запуска моих тестов.

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

Я использую VB Express 2010 и VS 2010, в зависимости от того, на каком компьютере я работаю, поэтому мне нужно будет провести тестирование на обоих. Я не собираюсь в ближайшее время конвертировать проект в C #, поэтому буду признателен за ответы, совместимые с VB.NET.

Спасибо!

Answer 1

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

Вывод отладки полезен при реализации новой функции.

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

Поскольку ваша процедура тестирования обычно выполняется только тогда, когда вы реализуете или расширяете некоторые функции «A», но не если вы изменяете код для функции «B», которая не должна быть связана с «A».Часто «A» и «B» имеют косвенное отношение, и реализация «B» сломает «A».Это называется ошибкой регрессии.

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

Однако гораздо труднее написать и поддерживать модульные, интеграционные и сквозные тесты с NUnit, чем применять тесты DesignByContract или тесты ManualVerifyDebugOutput вручную.

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