DocsV1.cls.xml

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

Heb het nog veranderd naar
Quit:(ProboxEtiketAfdrukkenRequest.DnaCodes.Count() = 0) ##class(TECH.ListIterator).%New()
kwestie van hoe dan ook een (lege) iterator terug te geven ipv helemaal niets

Finishing touch in $Case : zet na iedere komma een spatie. Dat verhoogt de leesbaarheid

Early-quit in het midden van uw code ... kan ik niet goedkeuren ... zeker niet omdat er een simpel alternatief is, dat wel oké is
Zet als eerste lijn van de method :

        Quit:(ProboxEtiketAfdrukkenRequest.DnaCodes.Count() = 0)

Commentaar is tegenstrijdig aan de assert-waarde ?

Kan je hier niet gewoon de ##class(TECH.FrequentieTabel) gebruiken ?

Hiere wa muggeziften voor gevorderden

Voor een buitenstaander is de code meteen begrijpbaar als je het gedrag in een boolean steekt : bvb.

 
  #dim ToonLijnReferentieOpTweedeRegel As %Boolean = ($$$HasLength(LijnReferentie))
  If ToonLijnReferentieOpTweedeRegel { ... 

en de "if" hieronder uiteraard ook.

Block van Toelevering etc. afzonderen in private method.
Of eventueel meteen method AssertLijnReferentie( ... ) van maken. Geen idee of dit properder zal zijn.

Block van OrderLijnen/OrderMock afzonderen in private method

Refactor UT aub.
Bij Tommy geef ik soms wel de opmerking dat de meerdere testmethods gelijke blokken code bevatten, waardoor het overzicht van de setup verloren gaat, en dus veel minder duidelijk is waar de variatiepunten in de tests zitten.
... dus moet ik dat ook bij u doen.

ProductInOrder is %Boolean --> $$$False i.p.v. ""

opgepast met haakjes.
Deze komt in de gevarenzone, vind ik.
Extra haakjes en spaties lijkt me niet overbodig. Tevens ook voor de leesbaarheid.

Zelfde opmerking :
ConfiguratorService naar constructor.

Zelfde opmerking :
LijnReferentieBepaler naar constructor.

Naar constructor verplaatsen.
zeker aangezien deze binnen de Loop Lijnen zit.