Модульное тестирование DAL - пожалуйста, критикуйте

Question

Я дошел до того, что в моем простом проекте я готов к модульному тестированию DAL.

У меня есть класс FooDataAccess с несколькими очень простыми функциями, скажем, 3 из них таковы:

int InsertFoo(string fooName)
void UpdateFoo(int fooID, string fooName)
void InsertFoosDepedency(int fooID, string someValue)

Я сделал следующее: поместил 4 сценария SQL в мой проект модульного тестирования, последний из которых является встроенным ресурсом.

1) Создать (модульный тест) сценарий базы данных, 2) Создать сценарий объектов, 3) Вставить значения таблицы поиска и 4) Удалить все, кроме значений таблицы поиска

Идея в том, что любой, кто первым использует проект, должен вручную запускать сценарии 1-3 вручную в качестве одноразовой установки. Затем выполните скрипт № 4 при запуске каждого модульного теста ... (в небольших приложениях вы можете даже запустить их все на уровне тестирования)

Хорошо, пока все хорошо ...

Итак, у меня настроена база данных модульных тестов, как с чистого листа. Тестирование первой функции InsertFoo () очевидно очень просто. Я вызываю функцию, затем просто Assert (ExecuteSQL (" select count (*) из foo ") > 1), Assert (ExecuteSQL (" select fooName из t_foo ") = ожидаемый)) и т. Д.

Я немного застрял там, где требуются зависимости, например, 3-я функция в моем примере или даже обновление.

Имеет ли смысл временно отменить все ограничения внешнего ключа для области моего теста? В противном случае, чтобы выполнить модульное тестирование функции InsertFoosDepedency (int fooID, string someValue), мне нужно было бы сначала выполнить какой-нибудь произвольный sql (вручную вставить запись в таблицу FOO и вернуть FooID) ...

ИЛИ, я должен просто сделать последнее?

Любые отзывы приветствуются.

ОБНОВЛЕНИЕ: он работает чисто с встроенным SQL для создания зависимостей. Я думаю, я просто ищу комментарии и Критика этого метода для модульного тестирования DAL. Еще раз спасибо

Answer 1

Это звучит очень похоже на то, что я делаю. Я уничтожаю все данные в базе данных при начале каждого теста , а затем собираю только то, что этот тест требует в этой фазе установки тестов. Так что для UpdateFoo у меня будет

void update_existingKey_updatesValue() {
   String expected = "jeff";

   clearDatabase();
   // Note I would use dbUnit.
   executeSQL("insert into foo values (1, 'fred')");

   DAL subject = new DAL(...);
   subject.update(1, expected);  

   //Note I would use dbUnit.   
   String actual = executeSQL("select name from foo where id = 1"); 
   assert(expected, actual);
}

В Java я использую инструмент под названием dbUnit , названия ваших методов предполагают C #, поэтому я укажу вам на dbUnit.Net , однако я никогда не использовал это. Это обеспечивает более приятный (во всяком случае, IMO) метод заполнения базы данных и проверки содержимого базы данных.

Answer 2

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

Можете ли вы использовать ложные объекты ?

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

Можно рассмотреть отдельный класс для каждого теста и использовать методы Setup и Teardown, чтобы привести базу данных в нужное состояние для тестов.

Или вам просто нужно выполнить настройку для конкретного теста в методе Test (и затем вы можете использовать Teardown для очистки БД).