Бази даних та тестування підрозділу / інтеграції

У мене з кимось було обговорено питання про тестування блоку / інтеграції з веб-додатками, і я не погоджуюся з приводу 1 основної ідеї. Проблеми полягають у тому, що людина, з якою я розмовляю, думає, що база даних, на яку працює тестовий блок, має попередньо заповнити дані, і я думаю, що вона повинна бути повністю порожньою до та після виконання тестів.

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

Здається, найкращим способом тестування функціональності бази даних було б наступні налаштування:

1. На етапі "налаштування" перед тим, як тест насправді запуститься, ви спочатку усіма таблицями в базі даних
2. Потім ви вставляєте всі дані, необхідні для тестових випадків, які ви збираєтеся запустити
3. Потім ви запускаєте і підтверджуєте тестові приклади
4. Потім у фазі "відриву" ви знову усікаєте всі таблиці в базі даних

Я не бачу іншого кращого способу гарантувати, що дані, на які ви тестуєтесь, є хорошим тестом.

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

Для мене одиничні тести не повинні мати справу з базою даних, інтеграційні тести мають справу з базою даних.

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

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

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

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

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

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

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

Ви маєте рацію в тому, як слід писати тести, за винятком того, що я б нічого не врізав:

• етап налаштування: встановіть підключення до бази даних та вставте дані
• фаза запуску
• фаза руйнування: видалення вставлених даних (усічення)

Тепер цей сценарій чудово підходить для одиничних тестів. Коли потрібні дані як для блочного, так і для інтеграційного тестування, я виявив, що одна велика фаза налаштування, спільна для всіх тестових випадків (ми перегрупували всі "вставки" в один статичний метод), може також працювати дуже добре. Це як середина між вашою ідеєю та ідеєю вашого друга. Єдиний недолік полягає в тому, що ви повинні бути дуже обережними, додаючи нові дані, щоб не порушити існуючі тестові випадки (але якщо ви додаєте як два-три рядки в таблицю, як ми, це не повинно бути проблемою)

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

Приклад: Перевірка таблиці транзакцій облікового запису

1. Ви не хочете перевірити перегляд цієї таблиці для користувача / облікового запису без транзакцій?
2. Тест додайте перший запис і подивіться, чи зможете ви створити баланс.
3. Створюйте записи, коли вже є записи, і перевіряйте поточний баланс та будь-які інші ділові правила.
4. Перегляньте таблицю з наявними записами та всіма іншими CRUD.

Чи досягаєте ви цього, виконавши кроки 1 і 2 або почавши базу даних, яка вже знаходиться в такому стані (відновити резервну копію?), Я не впевнений, що це має значення. Ваша ідея написання сценарію для мене полегшує управління будь-якими потрібними вам змінами (наприклад, якщо ви забули створити обліковий запис адміністратора і потребуєте його для нового користувача.). Файли сценаріїв легше піддавати керуванню джерелом, ніж деякі файли резервного копіювання. На це також впливає, чи розповсюджуєте ви цю програму чи ні.

Щоб скласти аспекти кількох відповідей разом і додати мою 2p ...

Примітка: мої коментарі стосуються тестування баз даних , а не тестування інтерфейсу (хоча, очевидно, це стосується)

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

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

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

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

Отже, даючи певний контекст моїй відповіді ...

Тестування одиниць

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

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

• Перевірка схеми, деякі можуть назвати це "випробуванням даних"
• значення стовпців, що проходять через
• здійснення логічних шляхів з різними значеннями даних для функцій, процедур, поглядів, обчислених стовпців
• крайовий тест - NULL, неправильні дані, негативні числа, занадто великі значення

(Одиниця) Інтеграційне тестування

Мені здається, що цей пост в SE корисний для розмови про різні типи тестування.

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

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

Це потім переходить на тестування системи , інтеграційне тестування системи ( так званий кінець 2-кінець тестування), зі збільшенням обсягів даних і збільшення обсягу. Усі ці тести повинні стати частиною системи регресійного тестування. Деякі з цих тестів можуть бути обрані користувачами для виконання як частини UAT, але UAT - це тести, визначені користувачами , а не такі, як визначено ІТ - поширена проблема!

Тож тепер, коли я дав деякий контекст, щоб відповісти на ваші фактичні запитання

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

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

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