JLM

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

Deze moet dan False teruggeven. Khad inderdaad wel wat moeite met een goeie naam te kiezen... en deze lijkt nogal afhankelijk van hoe ge het leest.
Het idee was: "Niet-BE Haefele Personality", dus een Haefele personality die niet HaefeleBE is. Ander idee is bijvoorbeeld "IsHaefelePersonalityMaarNietHaefeleBE" ofzo?

Nuja, het is volledig afhankelijk van hoe verschillende bedrijven die data doorsturen. Als er bvb een nieuwe dat exact zoals Haefele wilt doen dan moet die hier ook toegevoegd worden en dus moet de naam veranderd worden.

wat moet deze doen als bv SFS binnenkomt (of een andere personality die niets met Häfele te maken heeft?

Wanneer meer dan 90% van de klassen verwijderd worden, dan valt er nog weinig te reviewen. De blijvende implementaties uiteraard, die zijn "Review O.K."
Indien een klasse onterecht verwijderd zou zijn, zal ik als reviewer hier helaas niet kunnen opmerken.
Er zijn wel nog enkele deploy-klassen die verwijzen naar de package "APPS.common.KlantKost". Deze kan je best ook nog opkuisen.