Когда использовать тупики и насмешки?
Я только использую исключения, никакие коды возврата. Я говорю о Java здесь.
общее правило, за которым я следую, состоит в том, если у меня есть метод, названный doFoo() затем из этого следует, что, если оно "не делает нечто", на самом деле, затем, что-то исключительное произошло, и Исключение должно быть выдано.
5 ответов
У Мартина Фаулера есть хорошее обсуждение здесь .
Из его статьи:
Месарос использует термин Test Double как общий термин для любого типа воображаемого объекта используется вместо реального объекта в целях тестирования. Название происходит от понятия дублера в фильмах. (Одна из его целей состояла в том, чтобы избежать использования какого-либо имени, которое уже широко использовалось.) Затем Месарос определил четыре конкретных вида двойников:
- Фиктивные объекты передаются, но на самом деле никогда не используются. Обычно они используются только для заполнения списков параметров.
- Поддельные объекты на самом деле имеют рабочие реализации, но обычно используют некоторую комбинацию клавиш, которая делает их непригодными для производства (хорошим примером является база данных в памяти).
- Заглушки обеспечивают стандартные ответы на звонки, сделанные во время теста, обычно не отвечая ни на что, кроме того, что ' s запрограммирован для теста. Заготовки также могут записывать информацию о вызовах, например, заглушку шлюза электронной почты, которая запоминает «отправленные» сообщения или, возможно, только то, сколько сообщений «отправлено».
- Моки - это то, о чем мы здесь говорим: объекты, предварительно запрограммированные с ожиданиями, которые формируют спецификацию вызовов, которые они ожидают получить.
Из этих видов двойников только имитирующие объекты требуют проверки поведения.
Вы используете заглушки, когда просто хотите, чтобы функция возвращала какое-то значение (или ничего не делала). На самом деле вам все равно, вызывалась функция или нет, вы просто хотите изолировать вещи.
Моки более эффективны, так как вы также можете отслеживать, вызывалась ли функция, сколько раз, и даже делать что-то с значения, которые получает ваша функция.
В вашем случае, если вы хотите имитировать базу данных (чтобы она стала модульным тестом, а не функциональным), вы можете имитировать ISession и ITransaction. Затем вы можете сохранить эти значения в памяти и проверить, были ли сохранены правильные значения.
Да, использование реальной базы данных будет более функциональным или интеграционным тестированием, в зависимости от вашего определения. Лично я считаю, что модульные тесты предназначены для тестирования только этого метода, изолированного от всего остального. Таким образом, независимо от того, работает ли сеанс или транзакция или нет, ваш модульный тест должен гарантировать, что эти объекты будут вызываться для выполнения своей работы, когда и по мере необходимости - вот тут и появляются моки и заглушки. Вы используете их, чтобы гарантировать, что ваш модульный тест настолько отделен от внешних функций, чтобы его можно было протестировать как базовый модуль; в любом случае в идеале.
Большинство видов модульного тестирования - это тестирование отдельных частей кода, а заглушки и имитаторы - это просто инструменты, которые помогают вам в тестировании по частям. Тестируя детали по отдельности, вы, вероятно, сможете протестировать каждую деталь более подробно, но вы не получите никаких гарантий относительно полной картины. Для этого подойдут различные виды интеграционного тестирования.
При тестировании более крупных частей функциональности я часто нахожу фактические интеграционные тесты логики базы данных наименее ценными тестовыми артефактами, поскольку вы часто будете тестировать те же операции на уровне пользовательского интерфейса.
Вы должны тестировать код, который вы написали. Если вы написали объектный код подключения к базе данных, протестируйте его. В противном случае, если он является частью библиотеки со своими собственными тестами, вы можете просто имитировать / заглушить его и предположить, что если объект подключения передает свой собственный набор тестов, он работает.
Например, я бы не стал тестировать вызовы Методы Hibernate, я полагаю, разработчики Hibernate уже тщательно это протестировали. Но я проверил бы, что вызываю правильный метод, используя макет, чтобы установить это ожидание.