Spouštění testů pro několik částí aplikace

[lucienevludova-direct]

Dobrý den,

chtěla bych požádat o radu ohledně spouštění vícero testů. Aktuálně nám dlouhodobě běží test A, který od začátku do konce projede připravený scénář. Nyní máme připravený další scénář pro jinou část aplikace - test B. Předpokladem jsou další testy, které budou přibývat. Nyní se zaměřujeme primárně na jednu aplikaci, ale také aplikace by měly přibývat. Momentálně máme běžící dva soubory, a to smoke.yaml (smoke) a canarytrace.yaml (user-journey). Jak byste prosím doporučil nastavit spouštění testů? Je podle vás nutné či vhodné pro každý test/část aplikace mít vlastní yaml soubor? Nebo mít vždy jeden yaml pro každou aplikaci?
Zkoušela jsem spustit veškeré testy pomocí zápisu value: "dist/tests/*.spec.js". V Kibaně je možné dohledat podle souboru testB.spec.js, ten obsahuje informace i chyby o testech A i B. V původním testu testA.spec.js informace v Kibaně nejsou. Tady je tedy varianta mít všechny testy dané aplikace v jednom souboru např. test.spec.js. Tam ale vidím tu nevýhodu, že test nepoběží například každé dvě minuty, ale každých pět - než doběhnou všechny testy.

A ještě bych měla dotaz, soubor yaml máme nastaven na spouštění každých X minut, není možné nějak nastavit, že jakmile doběhne test, tak se spustí další? Nebude tedy čekat fixní minuty, ale bude probíhat kontinuálně?

Velice Vám děkuji za informace.
Nevludová

[rdpanek]

Dobrý den,

Canarytrace se snaží testovat co nejčistěji co to jen jde a z pohledu reálného uživatele - k tomu právě dopomáhá kubernetes, které pomáhá uzamknout prostředky prohlížeče a 100% odstínit od okolních vlivů.

Ideálním způsobem je držet se (patternu 1:1:1 tedy jeden testcase/user-journey, jeden engine a jeden prohlížeč)= tohle je právě uzavřeno v jednom podu, tedy jeden yaml jak popisujete, který má uvedenou revizi testcase a i jeho název. Je to z důvodu minimalizace nežádoucích účinků plynoucích z paralelního spouštění, chyb v prohlížeči atp.

Fixní délka cronjobu je bolístkou, kdy někdy je aplikace rychlejší a někdy pomalejší a pak POD čeká nebo zase nestihne doběhnout všechny teststepy. Zde je dobré si říct, jak dlouho má trvat user-journey a tak nastavit i cronjob, pokud je cronjob násilně ukončen ještě před koncem testu, protože se nestihlo dotestovat a kubernetes startuje nový pod, tak původní pod, který je ve fázi terminování stihne ještě do elasticu uložit právě tu informaci do c.report, že se nestihlo do testovat a to může být pro Vás validní výstup pro NFR.

Druhým způsobem, pokud chcete spouštět rotace více dynamičtěji, tak pomocí externího časovače / cronjobu / bashscriptu / pipeliny atp. Použijete bash script, který spustí v Kubernetes POD s Canarytrace, hlídá jeho životní cyklus a po dokončení můžete ověřit výsledky měření a testování a v zápětí spustit další test run tedy další POD s Canarytrace - tohle se používá právě v pipelnách.

Zde máme ze školení ukázku https://github.com/canarytrace/web-perf-scripts/tree/main/k8s-cicd která obsahuje canarytrace-pod.yaml ve kterém prakticky pokud nechcete, tak nic nemusíte měnit. Obsahuje ale zástupné znaky XXXX které mění za reálnou hodnotu následující pipeline.sh a tento sh skript použijete ve Vaší pipelině. Když se podíváte na životní cyklus pipeline.sh tak nazačátku se za XXXX nahrazují reálné hodnoty, pak POD spustí v Kubernetes, následně čeká na konec (zde se reálně čeká na opravdový konec testu nebo na timeout webdriverio), pak se běžící pod ukončí a celé kolečko může začít znovu.

Díky

[lucienevludova-direct]

Dobrý den, velice Vám děkuji za informace. Interně se tomu pověnujeme, v současném znění a rozsahu jsou pro nás nyní informace dostatečné.