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

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

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

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

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

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

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

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

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

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

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

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

Проблема вполне может быть в исходном вопросе. Некоторые из наиболее популярных примеров 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>, над которым можно было бы легко издеваться.