Ahogyan az már kiderülhetett az utóbbi időben a Go nyelv tanulásával foglalkoztam. Persze a "becsípődött" tesztelést sem tudtam elengedni. Így amikor az első feladat produktummá érett, rátértem a tesztelésre.
Most rövid összefoglalót olvashattok, hogy mire jutottam eddig.
A Ginkgo a teszter, a Gomega a matcher.
A Ginkgo a dokumentációja szerint BDD (Behaviour Driven Development) eszköz, de a példákból úgy láttam, unittesztre is alkalmas.
 
A Ginkgo — Gomega párosra esett a választásom, mert a tesztelő kód szerkezete, olvashatósága kedvemre való. A kód valójában öndokumentáló, ha nem vagyunk restek a leíró paramétereket kellő részletességű információval kitölteni.
  
Most, hogy megvolt az első bevetés, rájöttem, hogy inkább a modul viselkedését teszteltem.
  
A feladat során adat lekérdezést, feldolgozást, megjelenítést kellett végrehajtani. 
A tesztelés során azt kell igazolni, hogy a “beszerzett”, feldolgozott, formázott adat logikailag és formailag megfelel az elvártnak. 
 
Mivel az adat harmadik féltől származik, el kell érni, hogy rendelkezzünk referencia adattal, amihez az aktuális hívás eredménye hasonlítható.
A feladat szerint aktuális adatot kell lekérni. A szolgáltatónál lehetőség van ugyanannak a querynek csak a dátum paraméterét cserélve archív adat lekérdezésére. A feltételezéssel élve, hogy az archív adat nem változik, mind a referencia előállításakor, mind a teszteléskor azonos dátumot használva a teszt végrehajtható. 
  
Mivel nem kizárható, hogy az archív adat mégis megváltozhat, két lépcsősre terveztem a tesztet. Első lépésben a kapott valasz nyers adatait ellenőrzöm. Másodikként a formázott eredményt. Így ha a nyers ellenőrzés hibára fut indokolt lehet, hogy a kimeneti adat is eltérő legyen. Amennyiben csak a második teszt bukik el, a hibát a feldogozás + formázás lépéseiben kell keresni.
  
A referencia adatokat a teszt tervezésekor beszereztem, állományba mentettem. A tesztelés során az aktuális eredmény kerül a tárolt referenciával összevetésre.
A feldolgozatlan nyers eredményben szerepel a végrehajtás időpontjának bejegyzése. Szükséges ezt mind a referenciából, mind az aktuális adatból eltávolítani, különben hibára fut a teszt. 
  
A feldolgozást az olvashatóság és újra felhasználhatóság érdekében kisebb eljárásokra tagoltam (clean code elvek szerint). Unit tesztelés esetén minden eljáráshoz készül(nek) teszt(ek). Ha a kimeneti adat tesztje elbukik, hasznos lehet, ha rendelkezünk az elemi lépések tesztjeivel is. Így a kritikus eljárás tesztje is hibára fut. Továbbá hasznos tudni, hogy a módosítás okozott e hibát a módosított eljárásban, vagy keletkezett e következmény hiba máshol.
  
Jelenleg még csak a két, viselkedést ellenőrző, teszt készül el.

A bejegyzés trackback címe:

https://pharsan.blog.hu/api/trackback/id/tr8518043306

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása