Testování migrace dat

V posledních dnech jsme úspěšně spustili dlouho vyvíjený projekt a mám konečně čas něco napsat. Tématem dnešního příspěvku je testování migrace dat při přechodu na novou verzi nějaké aplikace.

Jako první věc je potřebné si uvědomit, co všechno obnáší migrace dat.
Obvykle se tím rozumí převod dat ve formátu "staré aplikace" do formátu dat "nové aplikace":

• načtení vstupních dat a jejich validace
• úprava a transformace dat do výstupního formátu podle pravidel migrace
• uložení transformovaných dat na správné místo pro novou aplikaci

Testování by mělo ideálně probíhat v těchto fázích:

1. Test kvality vstupních dat
"Stará data" nemusí nutně být konzistentní (a prakticky málokdy jsou) - za dobu života aplikace mohly být třeba dělány do databáze "manuální zásahy", které obcházely "business rules". Pokud namigrujete takto "znečistěná" data, můžete se dostat později do zbytečných problémů. V této fázi testů byste měli identifikovat:

• "typové sady" vstupních dat, které se budou migrovat
• záznamy nebo obecně část dat, která se migrovat nebude (třeba úplná historie zakázek atd.)

Testy by měly být zaměřeny na validnost všech migrovaných atributů vstupních dat a kompletnost těchto dat + že migrační skript vyloučí nevalidní nebo nemigrované záznamy (migrační skript by měl obecně detailně logovat průběh kvůli dohledávání chyb a monitorování průběhu migrace):

2. Test migrační transformace
Většinou je potřebné převádět nějaké hodnoty na jiný formát, nebo ukládat data do jiné struktury. Veškeré tyto změny by měly být popsány v dokumentaci a dokonale otestovány (včetně "nevalidních" hodnot, pokud jste tyto nevalidní záznamy nevyloučili z migrace již v 1.fázi).
Kromě toho, že se hodnoty správně transformují na nový tvar, je potřebné si ověřit, že se i uloží na správné místo - často se stává, že hodnota je sice správně, ale migrace ukládá pole do sloupce X v databázi, ale aplikace tuto hodnotu očekává ve slouci Y (důsledek častého psaní dokumentace během vývoje a nedostatečné komunikace migračního týmu a týmu co vyvíjí novou aplikaci).

Doporučený postup:

• nejdřív se udělá "rychlá kontrola" - počty namigrovaných záznamů v nových strukturách versus počty původních záznamů ve vstupních datech (ovšem při zohlednění pravidel migrace, třeba vypouštění historických záznamů)
• následně se alespoň na vybraných typových datech ověří správnost transformace a uložení hodnot jednotlivých entit na správná místa, včetně jejich provázání například v databázových tabulkách

3. Regresní testy funkčnosti na zmigrovaných datech
Tato fáze může velmi pomoci buďto odhalit "přehlédnuté" chyby ve fázi 2, nebo designové chyby/porušení business pravidel (třeba když se hodnota 1 sice správně transformuje na hodnotu "Ano", ale zapomnělo se, že nová aplikace načítává tuto hodnotu pořád do proměnné typu Integer).

4. Testy aplikace na nových datech
Tyto testy by měly být součástí normálního vývoje nové verze dané aplikace, nicméně pro migrační testy je podstatné nějak do databáze dostat k migrovaným záznamům i "nově vytvořena data" pro další fázi - je výhodné použít data z testů samotné aplikace.

5. Porovnání namigrovaných dat s nově vytvořenými v aplikaci
Kouknutím na jednotlivé záznamy můžete zjistit, jestli nová a namigrovaná data vypadají buď v aplikaci nebo na "nižší úrovni" - třeba v databázi - "přibližně stejně".
Nejde jenom o cíl "datové čistoty" - třeba se mi stalo, že migrace do pole parametrů namigrovala názvy parametrů A,B,C a nově vytvořený záznam měl tyto názvy X,Y,Z. Modifikace nad těmito záznamy samozřejmě selhala, jelikož aplikace očekávala jiné názvy parametrů.
Prakticky to kontroluji v databázi výběrem pár řádků s namigrovanými záznamy + pár řádků s novými záznamy a vizuální kontrolou. Už se mi tak podařilo odhalit pár velmi nepříjemných chyb, které unikly testerům v předešlých fázích.

Osvědčil se vám nějaký jiný způsob testování migrace, o který byste se rádi podělili? Vyjádřete se v diskuzi :-)