-
Notifications
You must be signed in to change notification settings - Fork 2
Description
De feedback van iteratie 3 op het STD-document moet verwerkt worden. Hieronder nog eens de commentaren van Ragnhild:
Sectie 4.2.1
"Wanneer de klasse wordt aangepast kunnen deze tests opnieuw gerunt worden."
Moeten?
"Bovendien kan Unittests testen ook het correct opslaan van data in de
database,"
Zinsconstructie? En inhoudelijk: akkoord met het vervolg van de zin,
en dat dit dus geen unit-test is (laat beter weg dus).
Sectie 4.2.2
"Bij unittests werd vermeld dat [...], in plaats van de werking van
slechts 1 component."
Erg veel redundantie. Beschrijf dit beter.
Integratietesten en tests die nog "higher-level" zijn, kunnen meer
bugs vangen omdat ze grotere stukken code testen.
Tegenargument: bij een integratietest wordt er maar een enkel
samenwerkingsaspect van een component getest, en kan men geen
uitspraken doen over ander, meer algemeen gebruik van die component.
Dus, er worden misschien minder bugs gevonden.
Je moet dus oppassen met zomaar concluderen dat integratietests meer
aandacht verdienen, en al zeker voor de opgegeven reden.
Sectie 4.2.3
Bedoelen jullie hier niet "acceptance tests"?
In de meeste (alle?) gevallen overstijgt de granulariteit van
functionaliteit van een requirement ruimschoots die van een unit test.
Het is ook geen slecht idee om een test suite te hebben die expliciet
requirements (groot en klein) test, zelfs als dit hier en daar
overlapt met andere, bestaande testen.
Ook hier is een betere bescrhijving nodig.
Sectie 4.2.4
"Deze moet blijven werken zoals verwacht met arbitraire input."
Wat wordt bedoeld met 'arbitrair'? Met verwachte en onverwachte input?
Selenium: vermeld wat jullie gebruiken of nodig hebben, dit is geen
handleiding over testing.
Sectie 4.4-4.5
Wat als een issue niet wordt opgenomen/afgewerkt? Wat is het scenario dan?