Самая большая проблема, с которой я столкнулся при использовании TDD, заключается в том, что разработчики не уверены в модульном тестировании.Плохое модульное тестирование тратит больше времени, чем экономит.Запутанные, ненадежные, не поддерживаемые, нечитаемые тесты очень быстро уходят на второй план, и разработчикам не хватает времени, чтобы снова захотеть выполнить модульное тестирование.
Per Fagrell делает некоторые хорошие замечания, особенно о запуске тестов после каждого изменения;Это должно стать второй натурой запускать тесты до и после любого изменения теста.
Каркасы:
Рассматривайте QUnit в качестве основы для тестирования JS: http://docs.jquery.com/Qunit
У меня есть страница с тестовым набором с зависимой разметкой, и тесты выполняются при загрузке страницы очень хорошо.
Вы можете выполнить
- Упорядочить
- Act
- Подтверждение потока
для модульных тестов с использованием QUnit.
Однако вам придется вручную выполнить настройку теста и демонтажметоды и вызывать их в ваших тестовых методах.Это поможет изолировать тестовые случаи, оставляя условия одинаковыми для всех тестов и предотвращая зависимость тестов от порядка их выполнения.
Ищите полезные платформы на других языках, которые вы будете использовать. NUnit очень популярен для .NET.
Изоляция:
Пер Фагрелл также делает хороший вывод об изоляции.Различие между модульным тестированием (тестирование одного аспекта атома функциональности) и интеграцией (тестирование того, как несколько атомов работают вместе) должно быть тщательно понято до начала тестирования.Если у вас есть более одного утверждения в методе тестирования, вы не проводите модульное тестирование и вам необходимо изменить метод тестирования.
Условные обозначения:
ХорошийСоглашение об именах от превосходного Искусство модульного тестирования для ваших тестов составляет MethodUnderTest_Condition_ExpectedBehaviour Например,
Expand_TextVariable_ExpandsText
С та же книга сохраняйте свои тесты:
- Достоверные
- Поддерживаемые
- Читаемые
В противном случае вы и другие разработчикине беспокойтесь о проведении испытаний.
Подделки:
Распространенным заблуждением является различие между двумя типами подделок: заглушки и mocks .
A seam создается в коде путем абстрагирования функциональности, от которой зависит код в интерфейсе.Например, контроллер не зависит от конкретного репозитория, он будет зависеть от IRepository.
A stub затем реализует этот IRepository и возвращает поддельные значения;он используется для изоляции кода контроллера для его изолированной работы.Например, GetCustomer() создаст нового клиента и вернет его без звонков в реальный репозиторий или какой-либо магазин. Заглушки никогда не проверяются на .
A макет похож на заглушку, за исключением того, что он может содержать значения, которые могут быть проверены.Например, AddCustomer(Customer customerToBeAdded), ваш макет примет это значение и может быть утвержден против. Моки могут быть проверены на .
Взгляните на Test Isolation Framework (или Mocking Framework), который может автоматически создавать подделки для данного интерфейса.
Недоразумениеиз-за использования mocks более одного разработчика, которого я видел, создали mock для тестирования функциональности, а затем написали тесты для самих mock.
Ресурсы:
Я упомянул Искусство модульного тестирования , и я рекомендую его полностью.Это одна из книг, наряду с Code Complete, которую я бы взял, если загорелся офис.
Надеюсь, это поможет.