Насмешливый против Тестовой БД?

Question

Ранее я задавал этот вопрос Как правильно выполнить модульное тестирование моего DAL? , одна вещь, оставшаяся без ответа для меня, состоит в том, что если для реального тестирования моего DAL нужно иметь тестовую базу данных, то какова роль насмешки против тестовой БД?

Чтобы добавить это, другой человек предложил «использовать транзакции и откат в конце модульного теста, чтобы БД был чистым», то есть протестировать БД. Что вы, ребята, думаете об этом подходе к тестированию + тестирование БД + откат транзакции (так что БД не написано)?

В завершение мой DAL построен на Entity Framework, в БД нет хранимых процедур. Поскольку EF настолько нов, мне действительно нужно протестировать DAL, чтобы убедиться, что они работают правильно.

Answer 1

Я думаю, что вы, вероятно, захотите провести некоторое интеграционное тестирование, чтобы проверить логику, которая обеспечивается вашей структурой базы данных, например, ограничения, триггеры, столбцы автоинкремента и т. Д. Однако для модульного тестирования вы должны макетировать любые компоненты инфраструктуры. что ваш DAL полагается так, как вы хотите (в своих модульных тестах) тестировать только те компоненты, которые вы кодировали. Вам не нужно тестировать методы на SqlCommand или SqlConnection (например). Вы должны предположить, что используемые вами компоненты инфраструктуры работают и создают для них заглушки или макеты, которые возвращают известные данные (хорошие, плохие, исключения) в ваши методы, чтобы убедиться, что ваши методы работают правильно. Без насмешек вы несете ответственность за создание данных в базе данных и обеспечение их правильности. Вы также оставляете открытыми зависимости от сети, самой базы данных и т. Д., Что может сделать ваши тесты хрупкими.

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

Answer 2

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

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

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

Answer 3

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

Answer 4

мы использовали транзакционные модульные тесты, и это несколько раз предотвращало проблемы с отображением в Hibernate. Иначе - что такое юнит-тест? Что-то тривиально, как List<Item> getAllItems()? :)

Answer 5

Вы не просто тестируете свое приложение. Вы также тестируете свою конфигурацию и свои хранимые процедуры и представления. Они задокументированы в ваших модульных тестах.

Answer 6

Проблема вполне может быть в оригинальном вопросе. Некоторые из наиболее популярных примеров MVC используют ярлык, возвращая DbSet, такой как:

public class MusicStoreEntities : DbContext
    {
        public DbSet<Album> Albums { get; set; }
        public DbSet<Genre> Genres { get; set; }
        public DbSet<Artist> Artists { get; set; }
        public DbSet<Cart> Carts { get; set; }
        public DbSet<Order> Orders { get; set; }
        public DbSet<OrderDetail> OrderDetails { get; set; }
    }

Для меня это тесно связано с реализацией настойчивости, которая, на мой взгляд, является плохой вещью. Лучше было бы вернуть List<t>, который легко подделать.

Answer 7

Необходимо учитывать не только состояние БД, но и доступность. Если ваша БД находится в автономном режиме, почему все ваши тесты DAL не пройдены?

Что вам нужно проверить, так это то, что ваш DAL выдает правильные команды для создания / получения / обновления / удаления. Для этого вам не нужно выполнять SQL, вы можете просто использовать инфраструктуру сохранения объектов и убедиться, что вы даете ему правильные инструкции.

Answer 8

Используя тестовую базу данных, вы открываете возможность возникновения проблем в самой базе данных или на пути связи (сеть и т. Д.) Между DAL и базой данных. Насмешка исключает эти возможности.