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

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

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

Често всички стари наработки попадат в забрава и всичко започва отначало. Няма никой, който да обича да се рови в чужд код, а ако имате време, защо да не се заемете със създаването на собствена система? Това е типичен подход и той е поради много причини правилен. Но в нашия проект не постъпихме така. В основата на бъдещата система за автоматично тестване заложихме наработките по 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. Тази статия се оказа не особено конкретна: тук има много текст и практически няма технически примери. Ако темата е интересна глобално, сме готови да я продължим и да се върнем с продължение, където ще разкажем за промените през последните шест месеца и ще приведем примери за код.

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

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