Mi a tesztelési keretrendszer scope-ja?

Question

Üdv!

A feladat szövegéből a csapatunk számára nem egyértelmű, hogy mi feladata, és mi nem feladata a tesztelő keretrendszernek.

A csapaton belül két értelmezés ütötte fel fejét:

• A keretrendszer feladata a megvalósított funkciókon kívül az, hogy a dinamikus tulajdonságokat fel tudja olvasni JSON-ból: vonatok elhelyezéses és mozgása, váltók állásának állítása. Ezek után az így definiált kezdőállapotból a definiált események lejátszása, tehát a rendszer meghajtása szimulációs adatokkal. A tesztek ezek után abból állnak, hogy a logok kimenetét összehasonlítjuk (emberi erővel) az elvárt, előre definiált működéssel.
• A keretrendszer feladata a fentieken kívül az is, hogy a JSON-ben elvárt végállapotokat definiáljunk szegmensekre, esetleg másra is. Ezek alapján a rendszer valamilyen módszerrel, valószínűleg az AbstractPahoMQTTClient saját kiterjesztésén keresztül feliratkozik az üzenetekre, ellenőrzi, hogy a megfelelők érkeztek-e meg, és automatizáltan (JUnit segítségével) eldönti, hogy a self-contained JSON-ben definiált teszt áll vagy bukik.

A kérdésünk tehát az, hogy a fenti két értelmezés közül melyik állja meg a helyét?

Answer 1

A tesztelő keretrendszer feladatai közé tartozik az is, hogy összehasonlítsa a JSON-ben elvárt állapotokat, így tehát a második értelmezésetek állja meg a helyét.

Arra figyeljetek, hogy mivel integrációt teszteltek és itt több lépésről is szó van egymás után, nem csak a rendszer végállapotát érdemes ellenőrizni.

Comments

Annyi kiegészítés, hogy az szándékosan nincs megkötve, hogy ezt az ellenőrzést hogyan valósítjátok meg. Lehet JUnit kódban, lehet később a log feldolgozásával, lehet valami referencia kimenet összehasonlításával (az integrációs tesztelés labor feladata kapcsán ez előjött, hogy itt már sokféle megoldás lehetséges). A feladat része, hogy erre egy jó karbantartható, skálázódó megoldást találjatok ki.

---

Köszönöm a válaszokat a csapat nevében!