AfbeeldingService

Je hebt een aantal imagecodes gecontroleerd, dat is oké.
Wanneer er nu een nieuwe MatKleur (of materiaal) bijkomt, dan zal deze test niet beginnen te falen. Logisch!
Als we zoiets wel willen, dan moeten we daarvoor een "SmokeTest" schrijven. Ik heb effe nagedacht, maar dat zou niet zo simpel zijn (gezien de combinatie van Materiaal en Kleur). Dus ik stel voor om het zo te laten, tenzij je zelf een briljant idee hebt.

Commentaar opkuisen :-P

... geeft lege AfbeeldingCode."

Ter informatie (om misverstanden in de toekomst te vermijden) :
Bij materiaal bestaat "antislip" en "antislip-Fiber"

Voor deze testmethods (naam) maakt het echt ni uit (dus ge hoeft het ni per sé aan te passen) maar let wel op als ge met andere mensen spreekt over "Antislip" terwijl ge "AntislipFiber" zou bedoelen.

$$$Implementation( MATImageCodeBepaler (i.p.v. "SST...")

en ook :
in nieuwe code gebruiken we $$$Inject i.p.v. $$$implementation

FormalSpec is copy-paste van LBX --> aanpassen naar MATImageCodeBepaler

Beter om de return-waarde ook nog te controleren.
Dus :
... DanReturn("UT_SpaceStepImage")
$$$AssertEquals(result, "UT_SpaceStepImage")

Reden:
De SSTImageCodeBepaler is de zogenaamde "black box" die een (willekeurig) resultaat teruggeeft. Het is een quick-win om deze te controleren als result van de "method under test".
Andere insteek :
ik kan de code in AfbeeldingCodeBepaler zeer gemakkelijk kapot maken zonder dat deze test dit aan het licht brengt. Door het resultaat te controleren, wordt het heel wat moeilijker om ditzelfde kapot te maken.