Як застосувати TDD для читання / запису функцій?

Це здається проблемою з куркою та яйцями.

Ви можете змусити функцію запису писати до якогось сховища даних, але ніколи не знаєте, що ви зберегли її належним чином без перевіреної функції читання.

Ви можете зробити функцію читання зчитуватися з сховища даних, але як ви можете розмістити речі в цьому сховищі даних для читання без перевіреної функції запису?

Редагувати:

Я підключаюсь до операцій із базою даних SQL, щоб зберігати та завантажувати об’єкти для використання. Немає сенсу тестувати функції доступу, які надає БД, але я обертаю такі функції БД, щоб серіалізувати / десеріалізувати об'єкти. Я хочу бути впевненим, що я правильно пишу та читаю потрібні речі до та з БД.

Це не так, як додавати / видаляти, як зазначає @snowman. Хочу знати, що вміст, який я написав, є правильним, але для цього потрібна перевірена функція читання. Коли я читаю, я хочу бути впевненим, що мій прочитаний правильно створив об’єкт, рівний тому, що було написано; але для цього потрібна добре перевірена функція запису.

Почніть з функції читання.

• У тестовій установці : створіть базу даних та додайте тестові дані. або через сценарії міграції, або з резервної копії. Оскільки це не ваш код, він не вимагає тесту в TDD

• У тесті : інстанціюйте своє сховище, вкажіть на свій тестовий db та зателефонуйте методу Read. Перевірте, чи повертаються дані тесту.

Тепер у вас є повністю перевірена функція читання, ви можете перейти до функції Write, яка може використовувати наявне Read для перевірки власних результатів.

Я часто просто пишу, а потім читаю. наприклад (псевдокод)

Foo foo1 = setup some object to write
File tempfile = create a tempfile, possibly in memory 
writeFoo(foo1, tempfile) 
Foo foo2 = readFoo(tempfile) 
assertEquals(foo1, foo2); 
clean-up goes here

Додано пізніше

Окрім того, що це рішення є "примматичним" та "досить хорошим", можна стверджувати, що інші рішення перевіряють неправильну річ . Тестування, чи збігаються рядки або SQL заяви, не є страшною ідеєю, я це робив сам, але це тестування побічного ефекту і є крихким. Що робити, якщо ви зміните великі літери, додасте поле або оновите номер версії у своїх даних? Що робити, якщо ваш драйвер SQL перемикає порядок викликів для підвищення ефективності, або ваш оновлений серійний інструмент XML додає додаткового місця або змінить версію схеми?

Тепер, якщо ви повинні дуже суворо дотримуватися деяких офіційних специфікацій, тоді я погоджуюся, що перевірка тонких деталей доречна.

Не варто. Не перевіряйте модуль вводу / виводу. Це марна трата часу.

Логіка тестування блоку. Якщо у коді вводу-виводу є багато логіки, яку ви хочете перевірити, вам слід перефактурувати свій код, щоб розділити логіку того, як ви робите введення-виведення і що ви вводите-виводите, чим ви займаєтесь від фактичної діяльності з введення-виводу. (що майже неможливо перевірити).

Щоб трохи уточнити, якщо ви хочете протестувати HTTP-сервер, вам слід зробити це через два типи тестів: інтеграційні тести та одиничні тести. Тестові пристрої взагалі не повинні взаємодіяти з В / В. Це повільно і вводиться багато умов помилок, які не мають нічого спільного з правильністю вашого коду. Блокові тести не повинні залежати від стану вашої мережі!

Ваш код повинен відокремлюватися:

• Логіка визначення того, яку інформацію надсилати
• Логіка визначення того, які байти надсилати, щоб надіслати певний біт інформації (як я кодую відповідь тощо в необроблені байти), і
• Механізм фактичного запису цих байтів у сокет.

Перші два стосуються логіки та рішень і потребують одиничних тестів. Останній не передбачає прийняття багатьох рішень, і їх можна чудово перевірити за допомогою інтеграційного тестування.

Це насправді хороший дизайн взагалі, але одна з причин цього полягає в тому, що це полегшує тестування.

Ось кілька прикладів:

• Якщо ви пишете код, який отримує дані з реляційної бази даних, ви можете перевірити, як відображати дані, повернуті з реляційних запитів, у вашу модель програми.
• Якщо ви пишете код, який записує дані в реляційну базу даних, ви можете перевірити, які фрагменти даних ви хочете записати в базу даних, фактично не тестуючи конкретні запити SQL, які ви використовуєте. Наприклад, ви можете зберегти в пам’яті дві копії стану програми: копію, що представляє, як виглядає база даних, і робочу копію. Коли ви хочете синхронізувати з базою даних, вам потрібно розмежувати їх і записати відмінності в базу даних. Ви можете досить легко випробувати тест, який відрізняє код.
• Якщо ви пишете код, який щось читає з конфігураційного файла, ви хочете перевірити аналізатор формату файлу конфігурації, але з рядками з вашого тестового файлу, а не з рядками, отриманими з диска.

Я не знаю, це стандартна практика чи ні, але це добре працює для мене.

У моїх реалізаціях методу читання, що не читаються, я використовую власні специфічні типи toString()та fromString()методи як деталі реалізації.

Їх можна легко перевірити ізольовано:

 assertEquals("<xml><car type='porsche'>....", new Car("porsche").toString());

Для фактичних методів запису читання у мене є один інтеграційний тест, який фізично читає і записує в одному тесті

До речі: чи є щось не так у тому, щоб один тест, який тест читали / писали разом?

Відомі дані повинні бути відформатовані відомим способом. Найпростіший спосіб здійснити це - використовувати постійний рядок і порівняти результат, як описано @ k3b.

Ти не обмежений константами. Можливо, існує ряд властивостей письмових даних, які можна витягти за допомогою аналізатора іншого типу, наприклад, регулярні вирази або навіть спеціальні зонди, які шукають функції даних.

Що стосується читання або запису даних, може бути корисним наявність файлової системи в пам'яті, яка дозволяє запускати тести без можливості втручання з інших частин системи. Якщо у вас немає доступу до гарної файлової системи в пам'яті, використовуйте тимчасове дерево каталогів.

Використовуйте ін'єкційну залежність та глузування.

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

Отже, коли у вас є метод / клас, який повинен щось робити з базою даних, нехай він не отримує це з'єднання з базою даних самостійно. Змініть його так, щоб об’єкт, який представляє з'єднання з базою даних, передається йому.

У своєму виробничому коді передайте власне об’єкт бази даних.

Під час тестування блоку передайте об'єкт макету, який просто поводиться так, що фактична база даних насправді не контактує з сервером бази даних. Просто перевірте, чи отримує він заяви SQL, які він повинен отримувати, а потім відповідає жорсткими кодованими відповідями.

Таким чином ви можете протестувати рівень абстракції вашої бази даних, навіть не потребуючи фактичної бази даних.

Якщо ви використовуєте об'єктний реляційний маппер, типово пов'язана бібліотека, яка може бути використана для перевірки правильності роботи ваших відображень, створюючи сукупність, зберігаючи її та перезавантажуючи її з нового сеансу з подальшим підтвердженням стану проти оригінальний об’єкт.

NHibernate пропонує тестування специфікації стійкості . Він може бути налаштований на роботу проти сховища пам'яті для швидких тестів на одиницю.

Якщо ви дотримуєтеся найпростішої версії шаблонів сховища та підрозділу роботи та перевіряєте всі ваші відображення, ви можете розраховувати на те, що дуже працює.