Що репозиторій робить, це перекласти з вашого домену на вашу базу даних DAL, наприклад, NHibernate або Doctrine, або ваші класи, що виконують SQL. Це означає, що ваш сховище буде викликати методи у зазначеній рамці для виконання своїх обов'язків: ваше сховище будує запити, необхідні для отримання даних. Якщо ви не використовуєте структуру ORM (сподіваюся, що ви є ...), сховище було б місцем, де будуються необроблені SQL-заяви.
Найбільш основним із цих методів є збереження: у більшості випадків це просто передасть об’єкт із сховища на блок роботи (або сеанс).
public void Save(Car car)
{
session.Save(car);
}
Але давайте подивимось на інший приклад, наприклад, отримання автомобіля за його посвідченням. Це може виглядати так
public function GetCarWithId(String id)
{
return Session.QueryOver<Car>()
.Where(x => x.Id == id)
.SingleOrDefault();
}
Все ще не надто складно, але ви можете уявити собі з численними умовами (дозвольте мені всі машини, зроблені після 2010 року для всіх марок групи "Фольксваген") це стає складним. Тож у справжній моди TDD вам потрібно це перевірити. Існує кілька способів зробити це.
Варіант 1: Знущаються над дзвінками до системи ORM
Звичайно, ви можете знущатися над об'єктом Session і просто стверджувати, що правильні дзвінки зроблені. Хоча це тестує сховище, воно насправді не тестово , тому що ви просто тестуєте, що сховище всередині виглядає так, як вам потрібно. В основному тест говорить, що "код повинен виглядати так". Тим не менш, це правильний підхід, але, здається, такий вид тесту має дуже мало значення.
Варіант 2: (Пере) побудувати базу даних з тестів
Деякі DAL-рамки дають вам можливість будувати повну структуру бази даних на основі створених вами файлів відображення для відображення домену на таблиці. Для цих рамок спосіб тестування сховищ часто полягає у створенні бази даних із базою даних пам'яті на першому кроці тесту та доданні об'єктів за допомогою DAL-фрейму до бази даних пам'яті. Після цього ви можете використовувати сховище в базі даних пам'яті, щоб перевірити, чи працюють методи. Ці тести проходять повільніше, але дуже справедливі та визначають ваші тести. Це вимагає певної співпраці з вашої DAL-системи.
Варіант 3: Тест на фактичній базі даних
Інший підхід полягає у тестуванні на фактичній базі даних та виділенні одиничного тесту. Це можна зробити декількома способами: оточіть свої тести транзакцією, очистіть вручну (не рекомендується так важко підтримувати), повністю відновіть базу даних після кожного кроку ... Залежно від програми, яку ви будуєте, це може або може не бути здійсненним. У своїх програмах я можу повністю створити базу даних локальної розробки з управління джерелами, і мої одиничні тести в сховищах використовують транзакції, щоб повністю ізолювати тести один від одного (відкрити транзакцію, вставити дані, тестовий сховище, відкатну транзакцію). Кожна збірка спочатку налаштовує базу даних локальної розробки, а потім виконує ізольовані транзакцією одиничні тести для сховищ у цій базі даних локальної розробки. Це '
Не тестуйте DAL
Якщо ви використовуєте рамку DAL, таку як NHibernate, уникайте необхідності тестувати цю рамку. Ви можете протестувати свої файли відображення, зберігаючи, отримуючи та порівнюючи об’єкт домену, щоб переконатися, що все в порядку (не забудьте вимкнути кешування), але це не так потрібно, як багато інших тестів, які ви повинні писати. Я, як правило, роблю це здебільшого для колекцій для батьків з умовами на дітей.
Під час тестування повернення ваших сховищ ви можете просто перевірити, чи збігається якесь ідентифікаційне властивість об’єкта вашого домену. Це може бути ідентифікатором, але в тестах часто корисніше перевірити читабельність людини. У "дістань мені всі машини, зроблені після 2010 року ....", це може просто перевірити, чи повернуто п'ять машин, а номерні знаки "вставте сюди список". Додатковою перевагою є те, що воно змушує задуматися про сортування, і ваш тест автоматично змушує сортувати. Ви здивуєтеся, скільки програм або сортують декілька разів (поверніть відсортовану з бази даних, сортуйте перед створенням об’єкта перегляду, а потім сортуйте об’єкт перегляду, все на тій самій властивості на всякий випадок ) або неявно припустите сортування сховища та випадково видаліть які були по дорозі, порушуючи інтерфейс користувача.
"Одиничний тест" - це лише назва
На мою думку, одиничні тести здебільшого не повинні потрапляти в базу даних. Ви будуєте додаток так, що кожен фрагмент коду, який потребує даних з джерела, робить це з сховищем, і це сховище вводиться як залежність. Це дозволяє легко глузувати і всі TDD-добрі ви хочете. Але врешті-решт, ви хочете переконатися, що ваші сховища виконують свої обов'язки, і якщо найпростіший спосіб це зробити, це потрапити в базу даних, так і нехай буде. Я давно відпустив думку про те, що "одиничні тести не повинні торкатися бази даних", і я зрозумів, що для цього є дуже реальні причини. Але лише в тому випадку, якщо ви можете зробити це автоматично і повторно. І погода, яку ми називаємо таким тестом, «одиничне випробування» або «тест на інтеграцію» - суперечка.