Является ли модульное тестирование нагрузкой?

Question

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

Скажет, у меня есть функция, которая:

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

Я думаю мне удалось правильно отдельный бизнес, данные и проблемы представления здесь: форма содержит только метод код представления, связанные, операции с данными являются звонки на DAL (Linq к SQL) и все согласовано на уровне бизнес-логики. Зависимости вводятся в конструкторы; например, форма хочет DataTable, а не имя файла рабочей книги Excel.

Если я думаю о тестах я мог (или должен) писать, я ... просто не могу думать о какой-либо, кроме тривиальных (бесполезные?) Те, которые VALIDATE что Foreach цикл делает ожидаемое число итерации, что функция GetMilimeterDimensions действительно конвертирует дюймы в миллиметры (например, проверьте, что GetMilimeterDimensions(new SizeF(1f,1f)) действительно возвращает SizeF { Width = 25.4, Height = 25.4 }.Чтобы читать это сейчас, похоже, что имя функции должно быть чем-то вроде ConvertInchToMilimeter и, это похоже на функцию который относится к статическому методу для некоторого BusinessMath. Плохой пример, я думаю.

Точка, все эти функции и методы, которые я хочу протестировать, - это все private и в конечном итоге вызывается классом COM-visible Execute(). Означает ли это, что я должен сделать их publicтолько для тестирования? Или, что, вставьте поведение моей функциональности в какой-то класс FunctionalityImplementation, который действительно раскрывает свои методы и вместо этого мои функции называют эти методы? Почувствуется как overkill ...

Тогда есть вызовы DAL; Мне нужно было бы реализовать некоторый шаблон репозитория, чтобы издеваться над CRUD-операциями и иметь возможность записывать тесты, которые проверяют, будет ли вставлено ожидаемое количество записей ... но это выходит за рамки проверки бизнес-уровня, я думаю.

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

Не поймите меня неправильно (с заголовком вопроса, я думаю), я вижу преимущества TDD, я читал книги ASP.NET MVC, написанные энтузиастами модульных тестов, но я просто не могу показаться оберните мою голову тем, как применять эти принципы к простой функциональности, не говоря уже о целом проекте библиотеки COM-видимых объектов ...

Answer 1

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

Но, возможно, вам не нужны модульные тесты для этого проекта.

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

Person *p = ...sample person....; 
LoanRequest loan(p, $1,000,000); 
Assert(loan.CanBeApproved(bankPolicy,region,market,term),true); 

Но это не важно, если основная логика проста и, видимо, правильно

Price=Total+Shipping; 

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

---

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