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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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