Является ли модульное тестирование вашего SQL слишком сложным?

Question

На www.sqlservercentral.com есть статья о модульном тестировании вашего SQL.

Парень из TDD сказал мне хорошо, мы можем протестировать базу данных.

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

Так что, если вы чувствуете необходимость модульного тестирования вашего SQL, вы просто очень тщательны, чрезмерно прагматичны или это признак запаха дизайна?

Answer 1

DbFit - хороший инструмент для модульного тестирования базы данных. Я думаю, что лучше использовать TDD с SQL, потому что, в конце концов, это декларативный язык с условным ветвлением, агрегатными функциями и так далее. Без тестов, как вы можете быть уверены, что получаете ожидаемый результат?

Answer 2

Пока предложение WHERE не пустое, оно должно быть проверено.

Здесь мы используем API-интерфейс NHibernate Criteria для запроса базы данных. Тем не менее, мы поставили простые модульные тесты для защиты уровня доступа к данным. Учтите это:

public IList<Book> GetBorrowedBooks(User user);

Это может выглядеть глупо в первую очередь. Но для такой простой ситуации мы имеем дело как минимум с 3 модельными объектами: Book, User, Borrow и, возможно, Return. Любая попытка изменить любой из 3 (или более) классов может привести к сбою кода.

Какова стоимость? Думаю, написание тестов в этом примере займет не более 20 минут. С помощью Category в NUnit модульные тесты доступа к данным могут быть настроены для запуска ночью, в то время как другие тесты запускаются при каждой фиксации. Медленные юнит-тесты доступа к данным не наносят вреда и спасают жизнь.