Скупой против тестовой базы данных?

Раньше я задавал этот вопрос Как правильно unit test мой DAL?, одно из вопросов, оставшихся без ответа для меня, - это, если действительно проверить, что мой DAL - это тест DB, то какова роль насмешки над тестовой БД?

Чтобы добавить к этому, другой человек предложил "использовать транзакции и откат в конце unit test, поэтому db чист", test db is. Что вы, ребята, думаете об этом тестировании + тест DB + транзакционный откат (так что db на самом деле не написан) подход к тестированию DAL?

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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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