Макет объектов против тестовой базы данных

Question

В чем преимущество использования фиктивных объектов по сравнению со статической тестовой базой данных, которая знает данные, и использованием транзакций, чтобы убедиться, что ничего не меняется при тестировании с базой данных.

Answer 1

Вы можете сделать оба. Используйте фиктивные объекты для проверки вашей логики BLL, а затем используйте тестовую базу данных для проверки вашей логики DAL. Таким образом, если что-то сломается, вы можете легко увидеть, в чем проблема, из-за которой тест не пройден.

Answer 2

Во-первых, использование макета будет намного быстрее, чем подключение к внешней базе данных.Однако основная причина заключается в том, что макеты ведут себя одинаково при каждом запуске теста, что невозможно гарантировать с помощью внешней службы, такой как база данных, что означает, что модульные тесты не могут быть случайными.Вы также можете легко смоделировать любые типы сбоев, которые вы хотите устранить с помощью фиктивного объекта.

Также рекомендуется запускать интеграционные тесты для реальной базы данных, чтобы проверить такие вещи, как конфигурация и производительность.

Answer 3

Если вы можете убедиться, что статический тестовый БД не изменяется во время тестирования, то я думаю, что статический тестовый БД лучше, чем фиктивные объекты.Но это зависит от того, что вы хотите протестировать, и от сложности тестируемого кода.Я бы пошел с фиктивными объектами, так как их проще поддерживать по сравнению с БД.

Answer 4

Настройка для тестирования с БД может быть трудной.Если вы обнаружите, что тратите больше времени на настройку БД, просто чтобы проверить какой-то функциональный аспект вашей бизнес-логики, тогда вы можете использовать макет / фальшивка.

Answer 5

Представьте, что вы собираетесь написать класс, который не существует.Может быть, это контроллер.Это не то, что напрямую говорит с базой данных.

У вас есть хорошее представление о том, как оно должно себя вести, и вы знаете, за что оно должно отвечать и что оно должно делегировать какой-то другой службе (используя SingleПринцип ответственности).Поэтому вы пишете интерфейсы для представления ролей вспомогательных классов, которые он собирается использовать.

Затем вы пишете пример того, как вы можете использовать свой класс, который собираетесь создать.Если хотите, можете назвать пример юнит-тестом.Вы макете взаимодействия с классами помощников.Когда вы запускаете пример, он терпит неудачу, потому что вы еще не написали код.Теперь вы можете написать код для его прохождения, используя интерфейсы вспомогательных классов - которые вы также еще не написали.

Затем вы делаете то же самое с вспомогательными классами, вычеркивая их помощников.

В конце концов вы достигнете класса, который обращается к базе данных.Или, может быть, это говорит с веб-сервисом.Или, возможно, данные являются статическими, или в памяти.(Это не имеет значения для исходного класса, потому что ваш класс отделен от этого).

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

При написании кода таким способом получается код, который легко использовать и понимать, и ничего лишнего, что не нужно для чего-то еще в стеке.Это обычно более надежно, чем код, который легче написать.Вот почему мы иногда используем mock - потому что написание тестов с использованием mocks помогает создать хороший, поддерживаемый, отделенный дизайн.

Answer 6

Обычно вы будете использовать оба этих подхода.

Для модульных тестов вы будете использовать фиктивные объекты.Таким образом, вы можете протестировать свою систему гораздо более детально, потому что вы можете макетировать все объекты, а не только те, которые обертывают соединение с базой данных.Как правило, рекомендуется проводить модульное тестирование каждого класса в отдельности от всех зависимостей.Преимущества заключаются в том, что можно проверить всю обработку ошибок на всех уровнях и убедиться, что вы проверили все пути кода, когда вы получите тестовый сбой, вы можете сразу найти причину и т. Д.

Для интеграции иСквозные тесты - вы тестируете большие части системы или все это.Затем вы должны подключиться к базе данных (потому что это соединение является частью теста).Очевидно, вы должны убедиться, что база данных находится в известном состоянии и т. Д. И т. Д.

В итоге у вас будет гораздо больше модульных тестов, чем интеграционных, поэтому на самом деле очень важно сделать их очень быстрыми - покаЕще одно преимущество использования макетов объектов.