Начало работы с модульным тестированием
-
08-06-2019 - |
Вопрос
Модульное тестирование — это, грубо говоря, тестирование частей вашего кода отдельно от тестового кода.Непосредственные преимущества, которые приходят на ум:
- Запуск тестов становится автоматизированным и повторяемым.
- Вы можете тестировать на гораздо более детальном уровне, чем тестирование «укажи и щелкни» через графический интерфейс.
Мой вопрос: каковы текущие «лучшие практики» с точки зрения инструментов, а также когда и где использовать модульное тестирование как часть вашего ежедневного кодирования?
Давайте попробуем быть в некоторой степени независимыми от языка и охватить все основы.
Решение
Хорошо, вот несколько лучших практик от человека, который не проводит модульное тестирование так часто, как следовало бы... кашель.
- Убедитесь, что ваши тесты проверяют одинвещь и только одна вещь.
- Пишите модульные тесты по ходу дела.Предпочтительно до вы пишете код, который тестируете.
- Не проводите модульное тестирование графического интерфейса.
- Разделите свои заботы.
- Минимизируйте зависимости ваших тестов.
- Ложное поведение с издевается.
Другие советы
Возможно, вы захотите посмотреть TDD на трёх индексных карточках и Три карточки, которые помогут легко запомнить суть разработки через тестирование:
Карта №1.Три закона дяди Боба
- Не пишите никакого производственного кода, кроме как для прохождения неудачного теста.
- Напишите только такой тест, чтобы продемонстрировать неудачу.
- Пишите производственный код только в количестве, достаточном для прохождения теста.
Карта №2:ПЕРВЫЕ Принципы
- Быстрый:Ум ошеломляюще быстро, сотни или тысячи в секунду.
- Изолированный:Тест четко изолирует неисправность.
- Повторяемость:Я могу запустить его несколько раз, и каждый раз он будет проходить или проваливаться одинаково.
- Самопроверка:Тест однозначно пройден-не пройден.
- Своевременно:Создано синхронно с небольшими изменениями кода.
Карта №3:Ядро TDD
- Красный:тест не пройден
- Зеленый:тест проходит
- Рефакторинг:чистый код и тесты
Так называемое xUnit Фреймворк широко используется.Первоначально он был разработан для Smalltalk как SUnit, затем превратился в JUnit для Java и теперь имеет множество других реализаций, таких как NUnit для .Net.Это почти стандарт де-факто: если вы скажете, что используете модульные тесты, большинство других разработчиков решат, что вы имеете в виду xUnit или что-то подобное.
Отличным ресурсом для «лучших практик» является Блог тестирования Google, например, недавний пост на Написание тестируемого кода это фантастический ресурс.В частности, их еженедельные публикации из серии «Тестирование в туалете» отлично подходят для размещения в вашем кубе или туалете, так что вы всегда можете подумать о тестировании.
Семейство xUnit является основой модульного тестирования.Они интегрированы в Netbeans, Eclipse и многие другие IDE.Они предлагают простое структурированное решение для модульного тестирования.
При написании теста я всегда стараюсь минимизировать использование внешнего кода.Под этим я имею в виду:Я стараюсь максимально свести к минимуму код настройки и демонтажа для теста и стараюсь максимально избегать использования других модулей/блоков кода.Хорошо написанный модульный код не должен требовать слишком большого количества внешнего кода при настройке и разборе.
NUnit — хороший инструмент для любого языка .NET.
Юнит-тесты можно использовать несколькими способами:
- Тестовая логика
- Увеличьте разделение единиц кода.Если вы не можете полностью протестировать функцию или раздел кода, значит, составляющие его части слишком взаимозависимы.
- Развивайте разработку, некоторые пишут тесты до они пишут код для тестирования.Это заставляет вас думать о том, что вы хотите от кода. делать, а затем дает вам четкие указания о том, когда вы этого достигнете.
Не забывайте о поддержке рефакторинга.ReSharper на .NET обеспечивает автоматический рефакторинг и быстрое исправление отсутствующего кода.Это означает, что если вы напишете вызов чего-то, чего не существует, ReSharper спросит, хотите ли вы создать недостающую часть.