Больше ошибок в модульных тестах, чем в производственном коде
Я только что запустил новый проект, и теперь с ASP.NET MVC, разрабатываемый чрезвычайно компонуемым способом, я полагал, что это могло бы быть хорошее время для запуска с поблочного тестирования. Большая часть моего кода нова, и я пишу тесты, прежде чем я напишу фактический производственный код.
Мое разочарование, тем не менее, состоит в том, что я трачу намного ошибки фиксации большего количества времени в своих тестах, чем в фиксации чего-то не так с моими производственными тестами.
Мой типичный рабочий процесс заканчивает тем, что был чем-то вроде этого:
- Запишите тупик
- Запишите тест
- Удостоверьтесь, что тест перестал работать
- Заполните тупик
- Тест все еще перестал работать, поэтому потратьте некоторое время, пробежавшись через ожидаемую и эффективную выходную мощность.
- Ошибка оказывается в тесте, не фактическом коде. Зафиксируйте тест.
Если Вы будете думать об этом, то это должно несколько ожидаться: модульные тесты включают вывод создания вручную, и так подвержено ошибкам; код, написанный на строгом языке и с хорошими методами кодирования, имеет поведение, которое указано очень автоматически.
Конечно, существуют нечетные времена, когда мой производственный код является фактической причиной тестового сбоя, но это просто действительно сравнительно редко.
Нет никакой причины устранить модульные тесты полностью, конечно; существуют времена, когда я просто не доверяю своему собственному коду вообще. С другой стороны, я начинаю чувствовать, что это не весь настолько ценно - особенно тест первая философия.
Кто-либо еще чувствует этот путь?
3 ответа
Я чувствую, что вы там, вот несколько вещей, которые я нашел полезными при написании модульных тестов, чтобы сделать их более надежными:
- Если вы еще этого не сделали, попробуйте разбить свои модульные тесты на одно утверждение на тест. Возможно, вам придется делать много утверждений на единицу кода, который вы тестируете, если методы массовые (это может означать, что ваши методы тоже должны быть разбиты). Но это упростит ваши модульные тесты и сделает их менее затратными по времени на обслуживание. Есть хороший шаблон для применения на практике, который называется Arrange, Act Assert (AAA)
- . Убедитесь, что ваши модульные тесты полностью изолированы, то есть нет никаких взаимодействий или вызовов вне вашего кода, то есть баз данных, веб-сервисов и т. Д.
- Используйте доступные фреймворки, чтобы упростить модульное тестирование и сделать большую часть работы за вас, например, Nbuilder для создания списков объектов и Moq для создания макетов объектов. вам нужно для тестирования.
- Если вы еще этого не сделали, используйте тестовые инструменты , чтобы вам не приходилось настраивать все для каждого теста.
TDD и модульное тестирование - это определенно то, с чего начинается настоящая боль в заднице, но это одна из тех вещей, которые становится намного легче и быстрее выполнять, чем больше вы будете уделять ей внимания.
В блоге Ричарда Дингволла есть немало статей о передовых методах модульного тестирования и TDD, многие из которых касаются модульного тестирования с помощью MVC.
Во-первых, TDD требует времени, чтобы адаптироваться к нему.
Мы как команда начали с TDD год назад. Первоначально мы начали с написания кода (класса / отдельного модуля), а затем написали тесты, покрывающие этот код.
Затем мы перешли к написанию тестов параллельно с кодом (напишите метод / группу методов, а затем напишите тестовые примеры, охватывающие эти методы). В течение этого периода мы использовали инструменты покрытия для проверки нашего покрытия.
Теперь, после года, когда команда хорошо разбирается в подходе, ориентированном на тестирование. @Scozzard упомянул важные моменты об использовании фреймворков AAA / mocking.
Если ваши тесты сравнивают фактические результаты с ожидаемыми значениями, написанными вручную (которые иногда вводятся неправильно), вы можете немного сэкономить, просто проведя рефакторинг ваших тестов. Вместо того, чтобы проверять, что метод X возвращает экземпляр, идентичный экземпляру теста, убедитесь, что экземпляр, возвращаемый методом, имеет то же важное свойство, что и экземпляр теста.