Начало работы с модульным тестированием

Семейство xUnit - это основа модульного тестирования. Они интегрированы в Netbeans, Eclipse и многие другие IDE. Они предлагают простое структурированное решение для модульного тестирования.

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

Широко используется так называемый фреймворк xUnit. Первоначально он был разработан для Smalltalk как SUnit, затем превратился в JUnit для Java и теперь имеет множество других реализаций, таких как NUnit для .Net. Это почти стандарт де-факто - если вы говорите, что используете модульные тесты, большинство других разработчиков подумают, что вы имеете в виду xUnit или аналогичный.

Отличный ресурс для «лучших практик» - это Блог тестирования Google, например, недавний пост на Написание тестируемого кода - фантастический ресурс. В частности, их еженедельные публикации из серии «Тестирование в туалете» отлично подходят для размещения вокруг вашего куба или туалета, чтобы вы всегда могли подумать о тестировании.

Хорошо, вот несколько лучших практик от человека, который не тестирует модули так часто, как должен ... кашляет.

1. Убедитесь, что ваши тесты проверяют один вещь и только одна вещь.
2. Пишите модульные тесты по ходу работы. Предпочтительно перед вы пишете код, который вы тестируете.
3. Не выполняйте модульное тестирование графического интерфейса.
4. Разделите свои проблемы.
5. Сведите к минимуму зависимости ваших тестов.
6. Имитируйте поведение с помощью издевается.

NUnit - хороший инструмент для любого из языков .NET.

Модульные тесты можно использовать по-разному:

1. Логика тестирования
2. Увеличьте разделение кодовых единиц. Если вы не можете полностью протестировать функцию или раздел кода, то составляющие его части слишком взаимозависимы.
3. Стимулируйте разработку, некоторые люди пишут тесты перед они пишут код для тестирования. Это заставляет вас задуматься о том, какой код вы хотите использовать для делать, а затем дает вам четкое указание, когда вы этого добились.

Вы можете посмотреть TDD на трех индексных картах и Три карточки-указатели, которые помогут легко запомнить суть разработки, основанной на тестировании:

Карточка №1. Три закона дяди Боба

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

Карточка # 2: ПЕРВЫЕ Принципы

• Быстро: невероятно быстро, сотни или тысячи в секунду.
• Изолированный: Тест четко изолирует неисправность.
• Повторяемость: я могу запускать его несколько раз, и каждый раз он будет проходить или терпеть неудачу.
• Самопроверка: Тест однозначно прошел / не прошел.
• Своевременность: создается синхронно с небольшими изменениями кода.

Карточка # 3: Ядро TDD

• Красный: тест не пройден
• Зеленый: тест пройден
• Рефакторинг: чистый код и тесты

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