Избегайте зависимости от базы данных для поблочного тестирования без насмешки

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

Тем не менее, извлеките код проверки в объект PersonValidator с помощью метода для логического isValid (Person). Затем в тестовом коде используйте фиктивный валидатор, который просто возвращает истину или ложь в зависимости от тестового примера.

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

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

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

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

Вам нужно просто настроить базу данных, которая будет использоваться для модульного тестирования. Если вы используете макеты для всего доступа к данным, вы на самом деле не будете много тестировать? :)

Почему вы именно пытаетесь избежать моков? Если вы собираетесь попрактиковаться в модульном тестировании и у вас есть код доступа к данным, проще всего будет освоиться с использованием метода mock / stub / inject.

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

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