LadeKlantEtiketBuilder.cls.xml

In verband met het statement : "QR-code ... staat op dezelfde plaats op het etiket als de barcode, dus ze mogen niet beide ingevuld zijn"

Optie 1 : in de software dit controleren/valideren en een exceptie smijten wanneer dit zich toch voordoet. De exceptie dan ook in UT opnemen : ZetVerwachteExceptie (je weet wel).
Optie 2 : in de UT tonen dat de software aanvaardt dat beide velden tegelijk ingevuld zijn, dus zonder exceptie te smijten. Hierbij wordt de verantwoordelijkheid dan naar Bartender (in dit geval) doorgeschoven.

Jij hebt hier gekozen voor Optie 2 (bewust of onbewust). Voor mij is dit oké.
Eventueel in die specifieke unit test method toelichten dat dit scenario problemen zal geven in Bartender.

De method under test : ToeleveringService.GeefLijnReferentie() kan ook in de Catch{} terecht komen.
Dat codepad kan dan best ook ge-unittest worden.
In dit geval zal de werkwijze wellicht iets anders zijn dan bij de gewone "ZetVerwachteExceptie()"
Bij twijfel, vraag gerus.

Bij deze exceptie-omschrijving staat bijzonder weinig info (geen eigenlijk) waardoor de persoon die dit moet troubleshooten sowieso extra tijd zal nodig hebben om uit te pluizen over welke Batch/klant/palletID/... dit hier gaat. M.a.w. tracht bij een exceptie steeds zoveel mogelijk context te scheppen. En indien dit niet mogelijk is in deze stacklevel, dan zeker checken dat er een Try-Catch op een hoger niveau gebeurt, waar wel meer context aan de exceptie toegevoegd wordt.

Deze opmerking hoort wellicht niet tot de review van deze story, dus feel free om door te geven aan de vorige owner

Over gecombineerde condities (i.e. conditie 1 en conditie 2 hebben een geheel andere context) en waarvan één conditie klantspecifieke filtering is, wil ik je nog een inzicht delen.
Uitleg ca. 5 à 10 minuten, dus graag effe samenzitten.

Enkele opmerkingen hierbij:
1) Het etiket zelf is: \\bartender\Bartender\Templates\ProboxLijnReferentieBarcode.btw
2) De DnaCodes in de batch zijn gegroepeerd op DossierCode en LijnReferentie. Vanaf 1 van deze verschillend is wordt een nieuwe 'groep' gemaakt. Echter gekozen voor een sorteeralgoritme omdat dit al bestond en ook wel op een logische manier werkt.
3) De LijnReferentieBepaler is verhuisd naar de ToeleveringService: er waren al 2 exacte dezelfde klasses plus tests hiervoor, een derde zou wat teveel worden. Daarom gekozen om het op een centralere plaats te zetten

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?