Больше ошибок в модульных тестах, чем в рабочем коде

Question

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

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

Мой типичный рабочий процесс заканчивается примерно так:

1. Написать заглушку
2. Написать тест
3. Убедитесь, что тест не пройден
4. Заполните заглушку
5. Тест все равно не пройден, поэтому потратьте некоторое время, просматривая ожидаемый и фактический результат.
6. Ошибка оказываетсябыть в тесте, а не фактический код.Исправьте тест.

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

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

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

Кто-нибудь еще так чувствует?

Answer 1

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

• Если вы еще этого не сделали, попробуйте разбить свои модульные тесты на одно утверждение на тест. Возможно, вам придется сделать много утверждений на единицу кода, которые вы тестируете, если методы массовые (это может означать, что ваши методы тоже должны быть разбиты). Но это ослабит ваши юнит-тесты и сделает их менее подверженными длительному техническому обслуживанию. Есть хороший образец для применения под названием Arrange, Act Assert (AAA)
• Убедитесь, что ваши модульные тесты полностью изолированы, т. Е. Нет никаких взаимодействий или вызовов вне вашего кода, т.е. баз данных, веб-служб и т. Д.
• Используйте доступные фреймворки, чтобы упростить ваш юнит-тестирование и выполнить большую часть работы за вас, например, Nbuilder для взлома списков объектов и Moq для макетирования объектов вам нужно для тестирования.
• Если вы этого еще не сделали, используйте тестовые приборы , поэтому вам не нужно настраивать все для каждого теста.

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

Блог Ричарда Дингвола содержит довольно много статей о передовых методах модульного тестирования и TDD, многие из которых касаются модульного тестирования с использованием MVC.

Answer 2

Во-первых, для адаптации к TDD требуется время.

Мы, как команда, начали работу с TDD год назад.Сначала мы начали с написания кода (класс / отдельный модуль), а затем написания тестов, охватывающих этот код.

Затем мы приступили к написанию тестов параллельно с кодом (написать метод / группу методов изатем напишите тестовые примеры, охватывающие эти методы). В течение этого периода мы использовали инструменты покрытия, чтобы проверить наше покрытие.

Теперь, выполнив это в течение года, команда хорошо разбирается в подходе, основанном на тестировании.@Scozzard упомянул правильные замечания об использовании AAA / mocking frameworks.

Answer 3

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