🥇Unit-тестове в СУБД — как го правим в Спортмастера, част втора

Първата част — тук..

Представете си ситуация. Пред вас е задача за разработване на нова функционалност. Имате разработки от вашите предшественици. Ако предположим, че нямате морални задължения, как бихте постъпили?

Най-често всички стари разработки потъват в забрава и всичко започва отначало. Никой не обича да се рови в чужд код, а при наличие на време, защо да не се заеме с изграждането на собствена система? Това е типичен подход и в много отношения е правилен. Но в нашия проект постъпихме по различен начин. В основата на бъдещата система за автоматизирано тестване заложихме разработки по unit-тестове на utPLSQL от предшествениците ни и след това започнахме работа в няколко паралелни направления.

Възстановяване на стари unit-тестове. Под възстановяване се разбира адаптация на тестовете към съществуващото състояние на системата за лоялност и адаптация на тестовете към стандартите на utPLSQL.
Решаване на проблема с разбирането какво точно, кои методи и процеси, са покрити от автотестовете. Трябва или да запомните тази информация, или да правите изводи на базата на самия код на автотестовете. Затова решихме да съставим каталог. На всеки автотест присвоихме уникален мнемокод, съставихме описание и записахме настройки (например, при какви условия трябва да се стартира, или какво трябва да се случи, ако стартирането на теста завърши неуспешно). По същество, запълнихме метаданни за автотестовете и поместихме тези метаданни в стандартни таблици на схемата utPLSQL.
Определяне на стратегия за разширение, т.е. избор на функционалността, която подлежи на проверка с автотестове. Решихме да се насочим към три неща: новите доработки на системата, инцидентите от продукцията и ключовите процеси на системата. Така развиваме системата паралелно с релиза, като осигуряваме по-високо качество и в същото време разширяваме обема на регресивното тестване и осигуряваме надеждността на системата в критични места. Първото такова тесно място беше процесът на разпределение на отстъпки и бонуси по касовата бележка.
Естествено, започнахме разработката на нови автотестове. Една от първите задачи при стартирането на проекта бе оценката на производителността на предопределени извадки от системата за лоялност. В нашия проект има блок с фиксирани SQL заявки, които избират клиенти по определени условия. Например, да получим списък на всички клиенти, чието последно пазаруване е било в конкретен град, или списък на клиенти, средната стойност на чиято покупка е над определена сума. След написването на автоматизирани тестове проверихме предопределените извадки, фиксирахме референтните параметри на производителността и освен това проведохме натоварващо тестване.
Работата с автоматични тестове трябва да бъде удобна. Най-често се извършват две действия: стартиране на автоматични тестове и създаване на тестови данни. Така в нашата система се появиха два помощни модула: модул за стартиране и модул за генериране на данни.
Модулът за стартиране е представен под формата на една универсална процедура с един входен текстов параметър. Като параметър може да се предава мнемокод на автоматичен тест, името на пакета, името на теста, настройките на автоматичния тест или резервационно ключово слово. Процедурата избира и стартира всички автоматични тестове, които отговарят на условията.
Модулът за генериране на данни е представен под формата на пакет, в който за всеки обект на тестваната система (таблица в БД) е създадена специална процедура, която вмъква данни там. В тази процедура максимално са попълнени дефолтните стойности, което осигурява създаването на обекти буквално с едно щракване. И за удобство на използване бяха създадени шаблони за генерираните данни. Например, да се създаде клиент на определена възраст с тестов телефон и извършена покупка.
Автоматичните тестове трябва да се стартират и да работят в приемливо време за вашата система. Затова беше организирано ежедневно нощно стартиране, в резултат на което се формира отчет за резултатите и се разпраща на целия екип по корпоративния имейл. След възстановяването на старите автоматични тестове и създаването на нови, общото време за работа беше 30 минути. Подобна производителност удовлетворяваше всички, тъй като стартирането се провеждаше извън работно време.
Но беше необходимо да се работи върху оптимизацията на скоростта на работа. Актуализацията на системата за лоялност в продукция се извършва през нощта. В рамките на един от релизите през нощта беше необходимо спешно да бъдат направени промени. Половинчасовото чакане на резултатите от автотестовете в три часа през нощта не направи отговорния за релиза щастлив (пламенен поздрав на Алексей Васюков!), а на следващата сутрин бяха казани много топли думи към нашата система. Но след резултатите беше установен 5-минутен норматив за работа.
За ускоряване на производителността използвахме два метода: автотестовете започнаха да се занимават в три паралелни потока, благодарение на архитектурата на нашата система за лоялност. И се отказахме от подхода, при който автотестът не създава за себе си тестови данни, а се опитва да намери нещо подходящо в системата. След извършените промени общото време за работа беше намалено до 3-4 минути.
Проектът с автотестовете трябва да може да се развива на различни стендове. В началото на пътя имаше опити да напишем собствени батници, но стана ясно, че саморъчната автоматизирана инсталация е истински кошмар и се обърнахме към промишлени решения. Поради това, че в проекта има много код (на първо място съхраняваме кода на автотестовете) и много малко данни (основните данни са метаданни за автотестовете), внедрението на Liquibase в проекта се оказа много просто.
Това е независима от базата данни библиотека с отворен код за проследяване, управление и прилагане на промени в схемата на базата данни. Управлява се чрез команден ред или фреймворкове като Apache Maven. Принципът на работа на Liquibase е достатъчно прост. Имаме организиран по определен начин проект, който се състои от промени или скриптове, които трябва да бъдат приложени на целевия сървър, и управляващи файлове, които определят в какъв ред и с какви параметри тези промени трябва да бъдат инсталирани.
На ниво на СУБД се създава специална таблица, в която Liquibase съхранява лог на обновленията. Всяка промяна има изчислен хеш, който постоянно се сравнява между проекта и състоянието в базата данни. Благодарение на Liquibase лесно прилагаме промените в системата ни на всеки контур. Автоматичните тестове в момента се стартират на тестовите и релизни контури, както и на контейнерите (лични контури на разработчиците).

И така, нека поговорим за резултатите от прилагането на нашата система за юнит тестване.

Разбира се, на първо място, сме убедени, че започнахме да разработваме по-качествен софтуер. Автоматичните тестове се стартират ежедневно и при всеки релиз откриват десетки грешки. Част от тези грешки обаче е само косвено свързана с функционалността, която действително искахме да променим. Има сериозни съмнения, че тези грешки биха били открити чрез ръчно тестване.
Екипът спечели увереност, че конкретната функционалност работи коректно… Това най-вече се отнася до нашите критични процеси. Например, през последните шест месеца не сме имали проблеми с разпределянето на отстъпки и бонуси в чека, въпреки ежерелизните промени, докато в предходни периоди периодично се появяваха грешки.
Успяхме да намалим броя на итерациите на тестването. Благодарение на това, че автоматичните тестове се пишат за нова функционалност, при аналитиците и същевременно тестерите попада код с по-високо качество, тъй като вече е бил проверен.
Част от разработките за автоматизирано тестване се използват от разработчиците. Например, тестовите данни на контейнерите се създават с помощта на модула за генериране на обекти.
Не е маловажно, че сме изградили „приемане“ на системата за автоматизирано тестване от страна на разработчиците. Има разбиране, че това е важно и полезно. А от личен опит мога да кажа, че това далеч не е така. Автоматичните тестове трябва да се пишат, да се поддържат и развиват, да се анализират резултатите, а често тези времеви разходи просто не си струват. Много по-лесно е да отидеш на продукция и да се справяш с проблемите там. При нас разработчиците се нареждат на опашка и просят да се покрият техните функционалности с автоматични тестове.

Какво следва

Нека поговорим за плановете за развитие на проекта за автоматизирано тестване.

Несъмнено, докато програмата за лоялност на Спортмастера е жива и продължава да се развива, можем практически безкрайно да развиваме автоматизираните тестове. Следователно основната посока на развитие е разширяване на обхвата.

С увеличаването на броя на автоматизираните тестове общото време за тяхното изпълнение неизменно ще нараства и отново ще трябва да се върнем към въпроса за производителността. Най-вероятно решението ще бъде в увеличаването на броя на паралелните потоци.

Но това са очевидните пътища за развитие. Ако говорим за нещо по-необичайно, нека отбележим следното:

В момента управлението на автоматизираните тестове се изпълнява на ниво СУБД, т.е. необходимите знания по PL/SQL са нужни за успешната работа. При необходимост управлението на системата (например, извършване на стартирания или създаване на метаданни) може да бъде изнесено в администраторски интерфейс, използвайки Jenkins или нещо подобно.
Всеки обича количествени и качествени показатели. За автоматизираното тестване такъв универсален показател е Code Coverage или метрика за покритие на кода. Чрез този показател можем да определим какъв процент от кода на нашата тествана система е покрит с автоматизирани тестове. От версия 12.2 Oracle предоставя възможности за изчисляване на тази метрика и предлага да се използва стандартния пакет DBMS_PLSQL_CODE_COVERAGE.
Нашата система за автоматизирано тестване е малко над година и, вероятно, сега е моментът за оценка на покритието. В моя предишен проект (проект, различен от Спортмастера) се случи точно така. След година работа по автоматизираните тестове ръководството постави задачата да оцени какъв процент от кода покриваме. При покритие над 1% ръководството щеше да е щастливо. Ние, разработчиците, очаквахме резултат около 10%. Добавихме измервания за покритие на кода, измерихме и получихме 20%. На радостта си отидохме да получим премия, но как точно отидохме и къде отидохме по-късно, е съвсем друга история.
Автоматизираните тестове могат да проверяват предоставените уеб услуги. Oracle напълно позволява това, а ние вече няма да срещнем редица проблеми.
И, разбира се, нашата система за автоматизирано тестване може да бъде приложена и в друг проект. Решението, което създадохме, е универсално и единственото, което изисква, е употребата на Oracle. Чух, че в други проекти на Спортмастера има интерес към автоматизираното тестване и, възможно, ще отидем при тях.

Изводи

Нека обобщим. В проекта на лоялност в Спортмастера успяхме да реализираме система за автоматизирано тестване. Основата й е решението utPLSQL от Стивън Фейерштейна. Около utPLSQL е разположен кодът на авто тестовете и помощните собствени модули: модул за стартиране, модул за генериране на данни и др. Авто тестовете се стартират ежедневно и, което е най-важно, работят и носят полза. Убедени сме, че започваме да произвеждаме софтуер с по-високо качество. Освен това полученото решение е универсално и може да бъде свободно приложено в всеки проект, където е необходимо организиране на автоматизирано тестване на СУБД Oracle.

P.S. Тази статия стана малко неясна: тук има много текст и почти липсват технически примери. Ако темата е интересна в глобален план, сме готови да я продължим и да се върнем с продължение, където ще разкажем какво се е променило през последните шест месеца и да дадем примери на код.

Пишете коментари, ако има моменти, на които трябва да обърнем внимание в бъдеще, или въпроси, които изискват разяснение.

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.