Як тестувати і налагоджувати бази даних

Самородов Федір Анатолійович : Як тестувати і налагоджувати бази даних

Автоматичне модульне тестування (unit test) коду програми - справа проста і ясна. А як тестувати базу даних? Або додаток, яке працює з базою даних. Адже база - це не просто програмний код, база даних - це об'єкт, що зберігає свої статки. І якщо ми почнемо в процесі тестування змінювати дані в базі (а без цього яке ж у нас буде тестування ?!), то після кожного тесту база буде змінюватися. Це може перешкодити подальшим тестів і необоротно зіпсувати базу даних.

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

Алгоритм такий:

1. відкриваємо транзакцію;
2. якщо потрібно, виконуємо підготовчі дії для тестування;
3. виконуємо модульний тест (або просто запускаємо сценарій, роботу якого хочемо перевірити);
4. перевіряємо результат роботи сценарію;
5. скасовуємо транзакцію, повертаючи базу даних в початковий стан.

Навіть якщо в тестованому коді залишаться незакриті транзакції, зовнішній ROLLBACK все одно відкотить всі зміни коректно.

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

Не поспішайте складати розподілені транзакції, є більш просте рішення! Штатними засобами SQL-сервера ви можете відкрити транзакцію на одному з'єднанні, а продовжити її на іншому.

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

Послідовність дій така:

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

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

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

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

У той час як для всіх інших сеансів дії додатка приховані блокуваннями ...

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

Або уявіть, що додаток починає працювати зі своїми версіями рядків в режимі SNAPSHOT. Як заглянути в ці версії? Навіть це можливо, якщо ви пов'язані спільною транзакцією!

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

Детальніше про це Ви зможете дізнатися на курсах SQL Server