Vlákno názorů k článku Spoiler Proxy: simulátor poruchy sítě od null null - Rád bych se zeptal jaká je výhoda, resp....
-
null null (neregistrovaný)
Rád bych se zeptal jaká je výhoda, resp. v čem je přidaná hodnota oproti klasickým testům?
Pokud byla aplikace napsána správně, zde dekompozice a ošetření error stavů odpovědí a timeouty, měly by requesty na externí zdroje být pomocí klasického mockingu dostatečné. Dovedu si představit že je toto vhodný způsob pro nějaké manuální testování před release - pak ale bez automatizace může být protestovat celou aplikaci (i nekolikrat) velmi otravné. S automatizaci to pak duplikuje normálni testováni. Tedy, jak by vypadal nejaky use-case v praxi?
-
Například:
Nastavím Spoiler Proxy. Pustím automatizované testy (pokud jsou k dispozici). V GUI Spoiler Proxy vidím, že se aplikace připojuje na databázi a RabbitMQ.První co mě napadne je, že přes Spoiler Proxy zruším spojení na databázi. Pak ho obnovím a sleduji, zda aplikace normálně funguje. Nepopadaly nějaké komponenty systému? Možná jsou tam nějaké asynchronní tasky, které se nedokončily. Funguje stále zpracování PostgreSQL notifikací? Nespadlo vlákno, které to má na starost?
Druhá věc, naruším spojení na RabbitMQ s BadReply. Tedy aplikace bude ukládat něco do externí fronty, dostane chybu, ale položka ve frontě už je. Jak aplikace reaguje? Nezačnou se tam data duplikovat?
Pokud mám k dispozici automatické testy např. přes JMeter, můžu zahrnout Spoiler Proxy do automatizovaných testů. Samozřejmě testy začnou padat. Důležité ale je, že po obnovení spojení bude vše fungovat dál a integrita dat zůstane v pořádku.
Konkrétní use case závisí na typu aplikace a co je pro nás je důležité. Někdy je důležitější dostupnost aplikace, jindy konzistence dat. V distribuovaném systému nemůžeme mít všechno (viz CAP teorém).
