Testování integrace

V každém komplexním systému, který je tvořen množinou nehomogenních subsystémů se nachází vrstva, která zajišťuje vzájemnou komunikaci těchto "nekompatibilních součástí" - integrace, alias integrační platforma. Často se dělá přímo na míru (každý klient si vyvíjí vlastní), nebo se upravují již existující řešení (například produkty Tibco).
V dnešním článku zmíním některé postupy, které je vhodné použít při testech integrační platformy.


Nejdřív malý úvod k tomu, jak integrace obecně funguje. Integrační platforma je vlastně most, který spojuje nehomogenní systémy - zjednodušeně řečeno na vstupu převezme požadavek systému A, transformuje ho do formátu systému B a odešle mu ho. "Vstupní" i "výstupní" rozhraní může být prakticky cokoliv - webové služby, databáze, EJB, message queues...
Kromě této základní funkce může mít integrační platforma (vlastně by měla mít :-)) i další vlastnosti - třeba monitoring provozu mezi systémy, rozložení zátěže, uchovávání zpráv v případě výpadků atd.

Testování integrace je vhodné rozdělit do následujících fází - co se bude testovat ve které fázi samozřejmě záleží na konkrétním projektu, tohle je spíše seznam "co se mi osvědčilo".

Unit testy

Jako první věc byste měli zajistit, aby byly vykonány důkladné unit testy - značně to sníží riziko "překlepových" chyb v pozdějších fázích. Je vhodné zaměřit testovací úsilí na korektní zpracování vstupních dat ve funkcích a ošetření výjimek (některé z výjimek budou jen obtížně simulovatelné z "vyšší úrovně", takže je pokryjte už v unit testech). Výstup, který byste měli v roli test manažera chtít = pokrytí jednotlivých komponent/funkcí v kódu testy a hlavně detailnější seznam toho, co pokryto nebylo.



Integrační testy

Jádrem celého testovacího snažení v této fázi by mělo být ověření řetězce "přijmu od systému A na vstupu zprávu X, transformuji ji na Y a uložím na výstup systému B" - čili korektnost transformace zpráv mezi systémy. Místo externích systémů se často používají simulátory, je ale vždy vhodnější použít reálný systém.
Vyzkoušejte veškeré možné (rozumné) kombinace systémů a variant jednotlivých zpráv, například u XML zpráv i povinnosti elementů a jejich formát ("string" není dostatečná specifikace, "telefonní číslo ve formátu XXXyyyyyy kde XXX je číselná předvolba a yyyyyy je číslo" již ano) atd.
Jako referenci použijte dostupné specifikace pro interfacy jednotlivých systémů a samotné integrační platformy (souběžně doporučuji dělat revizi těchto specifikací, často jsou tam odlišnosti a později to "vadí víc").
Pokud tuto část otestujete opravdu důkladně, ušetříte si neskutečné množství problémů a času v dalších testech (nebudete se muset později pídit "proč padlo zpracování XML uvnitř integrace", ale třeba jen "proč systém X nepřevezme zprávu z integrace").
V této fázi se velmi hodí použít automatizované testy, jelikož specifikace rozhraní se ještě budou s největší pravděpodobností v systémových testech "kosmeticky upravovat" a budou potřebné nějaké regresní testy.


Systémové testy

Táto fáze se občas spojuje s předchozí, nicméně je vhodné vnímat ji samostatně. Tady byste měli otestovat integraci tak, že fyzicky napojíte jednotlivé systémy na integrační platformu a testujete tak, že spouštíte jednotlivé "byznys procesy" v daných systémech a pouze koukáte do integrace, jestli vše probíhá v souladu s očekáváním; zlaté pravidlo = každá zpráva je generovaná reálným systémem, nikoliv simulátorem. Cílem je zjistit, že si systémy přes platformu "rozumí" i reálně, nejen podle specifikace.

Kromě toho byste měli otestovat:

• reálnou výkonnost integrační platformy (ideálně s připojenými systémy, v horším případě simulátory - budou zdrojem/cílem dat, ale měřit byste měli jen čas mezi obdržením požadavku na vstup a uložení požadavku na výstup integrace); pozor, různé typy požadavků jsou zpracovávány různě dlouho, tak s tím počítejte
• fail-over scénáře
• Jak se řešení bude chovat, když bude integrace nedostupná? Mají jednotlivé systémy nějakou "frontu"? Budou nějak notifikovány o nedostupnosti integrace? Dokáží se po jejím zpřístupnění samy "napojit"?
• Jak se řešení (nejen integrace!!!) bude chovat, když budou jednotlivé systémy (uvažujte "individuálně", ne v intencích "kterýkoliv ze systémů") nedostupné? Budou požadavky někde uloženy a později zpracovány (ručně, automaticky)? Neztratí se třeba při restartu serveru? Je integrace schopná se pak na tyto systémy sama napojit, až budou opět dostupné? 
• monitoring provozu (jestli se dají vytáhnout z integrace statistiky, jestli je logování dostatečné, jestli funguje notifikace o nalezení nezpracovaného požadavku administrátorovi atd.)
• simulace řešení provozních problémů - vyzkoušet jestli funguje přeposlání zprávy do cílového systému, nebo její manuální "oprava" a až následné přeposlání atd. - je vhodné souběžně psát příručku pro řešení těchto situací.

Akceptační testy

Pokud jste v roli dodavatele a udělali jste kvalitně předchozí fáze, tak se nejspíš budete jen usmívat, jak ty testy krásně odsýpají :-)  Pokud děláte akceptační testy jakožto zákazník, prakticky stačí udělat to samé, jako v systémových testech (záleží od rozsahu testů dodavatele a důvěry k němu).

Někdy příště se můžete těšit na pár dobrých nápadů pro testování specifických rozhraní (webové služby, databázové uložené procedury atd.).