Навіщо використовувати базу даних пам'яті для тестування інтеграції?

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

Що я тут пропускаю?

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

Перша ситуація, запускаючи тести під час розробки, слугує короткотерміновим цілям: визначення завдань (як у TDD: напишіть провальний тест, а потім пройдіть його), запобігання регресу, переконайтеся, що ваші зміни не порушують нічого іншого тощо. тести повинні бути надзвичайно швидкими: в ідеалі весь ваш тестовий набір працює менше ніж за 5 секунд, і ви можете просто запустити його в циклі поруч із IDE або текстовим редактором, поки кодуєте. Будь-яка регресія, яку ви запровадите, з’явиться протягом декількох секунд. Швидкі тестові пробіжки важливіші в цій фазі, ніж вилов 100% регресій та помилок, а оскільки розробляти на точних копіях виробничих систем недоцільно (або прямо неможливо), зусиль, необхідних для досягнення ідеального тестування тут, не варто. це. Використання баз даних пам’яті є корисним: вони не є точними копіями виробничої системи, але вони допомагають тримати пробні пробіги нижче 5-секундної межі; якщо вибір полягає в дещо іншому налаштуванні бази даних для мого тестування, пов’язаного з базою даних, і без тестування взагалі, я знаю, що я вибираю.

Друга ситуація, переміщення коду по ланцюжку розвитку, однак, робить вимагає ретельного тестування. Оскільки ми можемо (і повинні) автоматизувати цю частину процесу розробки, ми можемо дозволити собі набагато повільніші тести - навіть якщо повний тестовий пробіг займає години, планування нічного складання все ще означає, що ми завжди маємо точну картину вчорашньої бази коду. Зараз важливо моделювати виробниче середовище як можна точніше, але ми можемо собі це дозволити. Таким чином, ми не робимо компромісу в базі даних пам'яті: ми встановлюємо таку ж версію точно такої ж СУБД, що і виробничі системи, і, якщо можливо, наповнюємо її фактичними виробничими даними до початку тестування.

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

Інтеграційні тести працюватимуть повільніше, але коли вони швидкі, ви можете запускати їх частіше. Наприклад, перед кожним вчиненням. Звичайно, це не так повно, як повноцінне середовище, але принаймні ви протестуєте шар відображення, створений SQL, як частина спілкується між собою і т. Д. У разі дорогої бази даних ви також переконайтеся, що ви не робите ' не потрібно купувати ліцензію для всіх. Ви можете зафіксувати більше помилок, покриваючи 90% коду тестами, проведеними один раз на годину, ніж покриття 100% тестування коду один раз на день або, що найгірше, тиждень.

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

Для виконання простих тестів цілком прийнятні глузування з шару доступу до бази даних. Ви дзвоните getName(), він називає DAO, що знущався і повертає "Джон" за ім'ям і "Сміт" за прізвищем, збирає їх і все ідеально. Тут немає необхідності перевіряти базу даних.

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

У деякому фактичному коді, над яким я працював (точка продажу), у нас був resumeSuspededTransaction(...)метод. Це витягнуло б транзакцію з бази даних в об'єкт (та її компоненти) та оновило базу даних. Ми знущалися над цим, і помилка ховалась у коді десь із серіалізацією та десеріалізацією даних, що надходять до бази даних (ми змінили тип, який серіалізувався по-різному в базі даних).

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

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

У пам'яті баз даних є переваги:

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

Це багато що залежить від системи бази даних, яку ви використовуєте. Коли ваша система db надає вам альтернативу в пам'яті, яка майже 100% API та поведінка, сумісна з конфігурацією бази даних на диску (за винятком швидкості та безвідмовної безпеки, або курсу), то використання варіанту пам'яті очевидно добре .

Однак якщо у вашій системі БД є значні відмінності між конфігурацією пам'яті та використанням не в пам'яті, ви маєте рацію: у цьому випадку тести на інтеграцію мають більший ризик затінити помилку. Але навіть тоді ви, можливо, зможете "абстрагувати ці відмінності" самостійно, враховуючи, що ви добре знаєте свою систему БД та відмінності.

Словами мирянина:

Знущання з важливих частин архітектури добре (і обов'язково) для тестування одиниць .

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

Зрештою, інтеграційні тести - це тестування того, як різні частини архітектури поводяться разом.