ImageLink.cls.xml

No big deal.
Codebase in t Nederlands, maar StringUtils.Replace() is Engels, dus wellicht geen taal-reset van mijn brains

Maar in feite zetten we geen commentaar in onze code (= clean code principle!)
Hier, in dit specifiek geval is het echter om te benadrukken dat ALLE spaties moeten vervangen worden.
Uitzondering bevestigt de regel.

Algemene vraag:

Ik heb als PM tester enkele opmerkingen in het Jira ticket geplaatst.
Moet ik hier al reviewer rekening mee houden tijdens de review?

De uitleg van Tom was dat de reviewer enkel de kwaliteit van de code moet beoordelen.
Maar er is een optie 'factually incorrect' in de tool, en mogelijks vallen enkele van mijn opmerkingen onder deze noemer?

Graag advies.

Style:

• Codebase is volledig in het Nederlands, waarom deze comment dan in het Engels?

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

Ik vermoed dat vhUnitTest.APPS.Halux.Docs.TestDataEtiketten nergens anders gebruikt wordt en dus mag opgekuist worden hé

Info2 wordt wel geassert, maar doet niet echt ter zake in deze UT. Toch niet volgens de naam ervan.

Ik zou de UT-naam iets duidelijker maken, want "Klant OrderNummer" houdt eigenlijk pas steek als voorgaande UT in acht wordt genomen en mettertijd staan die 2 UT misschien niet meer vlak bij elkaar. Ik zou ook, net zoals hierboven, vermelden dat het over het veld Info1 gaat.

Misschien nog bijzetten "in Info1";

Ofwel klopt de naam van de UT niet, ofwel de implementatie. Er is geen assert op ProductImg en als ik die toevoeg (met een verwachte waarde anders dan leeg), dan slaagt de test, terwijl ProductImg volgens de UT-naam leeg zou moeten zijn!
In de "oude" UT ontbrak die assert blijkbaar ook en de UT-naam is ongewijzigd volgens deze review, dus zou er eens nagevraagd/nagekeken moeten worden wat eigenlijk de bedoeling is, zodat het juiste kan aangepast worden.

Ik zou de projectreferentie hier en in de volgende Unit Test vooraf in een variabele steken met een duidende naam, zodat het wat meer opvalt. Duurde even voordat ik doorhad dat in de volgende UnitTest het 2-tje weg was en aangezien dàt het enige verschil is mag het wel wat opvallen

Is het niet een beetje raar dat deze properties nu leeg zijn voor de assert? Worden blijkbaar niet mee uitgemockt?