Verificatie van foutafhandeling middels testing

[alienfruit]

Gisteren ben ik begonnen aan een nieuw project op mijn werk. Omdat het eigenlijk een gedeeltelijke rewrite van een bestand product is. Wil ik graag gebruik gaan maken van verificatie en testing. Omdat het systeem erg afhankelijk is van wanneer specifieke data binnenkomt wil ik dit graag automatische testen. Vooral omdat er andere dingen moeten gebeuren.

Een kleine voorbeeld:
Er loopt een campagne met een tijdsduur van 10 minuten binnen deze 10 minuten wordt er elke drie minuten een prijs getrokken (door een remote server). Deze server verstuurt vervolgens het resultaat door naar de terminal. Alleen als dit resultaat te laat aankomt dan moet het systeem een foutmelding geven totdat de volgende trekkingsresultaat binnenkomt. Bij elke trekking wordt ook de verwachte tijdstip van de volgende trekking meegestuurd. Nu wil ik dit graag testen. Ik heb een hele reeks datasets met alle combinaties qua resultaten van de externe server. Maar hoe kan ik dit testen?

Overigens is het bovenstaande een simpel voorbeeld. Denk maar meer aan dingen als:

1. Is het resultaat van vandaag?
2. Is het resultaat ouder dan halve minuut?
3. Is het resultaat ouder dan een minuut?
4. Is het resultaat ouder dan twee minuten?
5. Is er nu een prijs gewonnen?
6. Is er bij de vorige trekking een prijs gewonnen?
7. Is de prijs in deze winkel gewonnen?
8. Is de prijs in de regio gewonnen?
9. Is het een prijs uit de categorie laag?
10. Is prijs uit de vorige trekking uit de categorie laag?

In het echt heb ik te maken met een flowchart waar je gewoon bang van wordt. Elke keer een andere verloop van de campagne. Daarom wil ik dus een state machine gebruiken met een reeks guards voor elke state (trekking, reclame, foutmelding).

Ik heb zelf nagenoeg geen ervaring met TDD moet ik zelf toegeven. Volgens mij noemen ze dit integratie testen? Moet je dan elke actie in het systeem loggen en vervolgens na de testrun controleren of de acties in de verwachte volgorde is uitgevoerd? Of heb je gewoon unit tests voor elke onderdeel van de terminal en ga je er vervolgens maar vanuit dat het werkt?

[ Voor 21% gewijzigd door alienfruit op 30-04-2011 13:40 ]

[D-Raven]

Waar je op moet focussen is om een architectuur op te zetten waarin dit geheel testbaar is.
Klinkt eenvoudig .

Een idee zou kunnen zijn dat je je acties afzonderlijk definieert (en dus testbaar maakt) waarbij je dingen zoals IoC en SRP toepast. Op die manier kun je all je afzonderlijke business acties testen.

Vervolgens pas je een vorm van compositie toe om je acties te combineren naar het geheel, dit is dan je integratie test. Namelijk de test die controleert of de acties in de juiste volgorde zijn samengesteld.
Ik kan me voorstellen dat dit nog steeds een beetje vaag overkomt, maar ik kan later als je wilt nog wat abstracte code examples posten, om je wellicht een beter idee te geven.

[JustMitchie]

ja
voeg iets toe of post niks...

[ Voor 90% gewijzigd door RobIII op 30-04-2011 16:57 ]

[alienfruit]

Ja, ik was van plan om een state machine [1] te gebruiken en vervolgens de enter exit guards van de verschillende state implementaties testbaar te maken. Als elke state zijn eigen klasse heeft kan je de overige delen mocken (trekkingsresultaat model). Zodoende kunnen controleren of de guard op basis van de gemockte model naar de correcte state wordt gezet (transitie)

Ik heb een unit test gevonden van de state machine library die er veelbelovend uitziet: https://github.com/AS3Sta...StateMachineGuardTests.as

Maar wat als je vervolgens ook de terminaal wilt draaien voor een uur of te kijken of alles soepel loopt. Met unit tests test je immers alleen de losse klasses en niet het geheel.

[1] https://github.com/AS3Sta...tateMachine-for-Robotlegs

[ Voor 12% gewijzigd door alienfruit op 30-04-2011 17:21 ]

[D-Raven]

Vrij lastig. Het kan wel maar het is gewoon veel werk. Je zult een omgeving moeten programmeren waarin je state machine virtueel kan draaien. Maar deze omgeving zal dan niet zomaar random waardes mogen genereren, ze moeten wel passen in wat de state machine toelaat.

Is het dan niet veel eenvoudiger en effectiever om al je state transities te testen? Als die allemaal werken dan zou het niet uit mogen maken in welke volgorde je transities aangeroepen worden, of hoe vaak (lang). Tenzij je tests niet goed zijn

[alienfruit]

Ja, state transities zou dan vallen onder unit tests? Verder kan ik wel gebruik maken van een reeks "fixtures" voor het testen van het systeem. Het gaat hier immers om XML bestanden die worden geupload door een externe server. Ik zou dan gewoon die bestanden op n minuten zelf overschrijven met de laatste versie.

[D-Raven]

alienfruit schreef op maandag 02 mei 2011 @ 08:58:
Ja, state transities zou dan vallen onder unit tests?

Yup

Verder kan ik wel gebruik maken van een reeks "fixtures" voor het testen van het systeem. Het gaat hier immers om XML bestanden die worden geupload door een externe server. Ik zou dan gewoon die bestanden op n minuten zelf overschrijven met de laatste versie.

Als het uiteindelijk zoiets (relatief) eenvoudigs is, dan zou je dat kunnen doen, maar realiseer je wel dat je dan een integratie test aan het maken bent.

Dat gezegd zou ik alsnog Unit Tests maken voor je state transities, met de integratie test zul voornamelijk testen dat het bestand in een x scenario's succesvol opgepakt wordt. Dat je state machine het vervolgens op de gewenste manier verwerkt is pure bijzaak en zou de uitkomst van je integratie test niet mogen beïnvloeden. Dit vang je immers af met andere tests.
Voor tests geld ook het SRP principe. Hoe meer een test doet (unit of integratie), hoe lastiger het wordt om een conclusie te verbinden aan het feit dat je test faalt of succesvol is.

[alienfruit]

Ja, dat snap ik. Het niet veel zin om meerdere dingen in een unit test te gaan testen. Maar goed, ik ga eerst maar een plan maken en vervolgens maar enkele unit tests te schrijven voor bestaande functionaliteit. Het parsen van de XML bestanden e.d.

Ik vind het altijd lastig wat te testen voor een klasse. Ik heb bijv. een klasse die elke 30 seconden een map controlleert of de content van enkele bestanden veranderd is. Zo ja, moet het een event dispatchen. Maar hoe test je zoiets?

[D-Raven]

Door die 2 verantwoordelijkheden uit elkaar te trekken. Maak een klasse die kan controleren of de content van bestanden in een map is veranderd, en maak een klasse die deze klasse elke x seconden uitvoert en een event opgooit.
Dan wordt het bedenken van hoe je test in elkaar zou moeten steken een stuk eenvoudiger.

Overigens ben je bekend met de FileSystemWatcher?

[alienfruit]

Ja, ik ken die klasse alleen maak ik gebruik van Flash
Verder moet ik eerst de baas zo gek krijgen dat ik de boel wat mag opschonen. De eerste reacties zijn niet echt positief... Hij dacht dat ik zo 1-op-1 het oude project kan hergebruiken. In principe kan dat ook wel maar het is sneller op de boel meteen te refactoren en op te schonen ipv. bestaande code te hacken. Code waarbij je gemakkelijk nieuwe fouten of bugs kan introduceren.