Legacy

De stat juist, Heb ik bewust gewijzigd. Anders krijgen we standaard het gedrag dat spoelbak en smalle lade altijd in spoelbakgroep terecht komen en default gedrag is dat dit niet gebeurd. daarom heb ik ook de altijdsplitser moeten toevoegen.
maw indien true, faalde de bestaande testen op gewone aantallen als er geen splitser meegegeven wordt..

(Ik vind het nog steeds een gevaarlijk iets om te beslissen dat de groepering per kenmerk vervangen wordt door groepering op productiegroep, terwijl het in dit geval toevallig hetzelfde is.)

Kritische vraag (misschien om in de groep te gooien) :
Is dit een project-setting? --> volgens mij enkel bedoeld om iets nieuw te kunnen "infaseren". Nadien wordt een project-setting opgekuist (in theorie althans )
Is dit dan eerder een gewone ConfigItem? --> is eigenlijk bedoeld om onderscheid te kunnen maken tussen de verschillende omgevingen (bvb. andere waarde op PROD dan op DEV)
Is het voldoende om deze gewoon als Class Parameter te definieren? --> volgens mij wel. Dit is een single-responsibility klasse, dus een wijziging van de waarde committen en mergen, kan supersnel.

Willen we dit toch wegtrekken uit onze code, dan misschien toch een aparte data-structuur voor maken. Functioneel is config-item hiervoor ook wel geschikt, maar ik vraag me af of we den boel dan niet te veel gaan vervuilen?

Ook testmethod maken met
VerwachtMethodCall("IsNodigTeSplitsen" --> dan Return False

ToeleveringSplitserMock.Verifieer()

AltijdSplitser kan best in de constructor, want nu krijg je een nieuwe instantie bij iedere "VoegToe"-call.

Quit $$$True
(want ik zie dat de UT-resultaten gewijzigd zijn, en dat was niet de bedoeling )

Deze klasse mag weg, indien geen Config-item gebruikt wordt. (zie opmerking bij ToeleveringSplitser)

Deze klasse is niet meer nodig, denk.

Deze klasse is niet meer nodig, denk.

Klein detail : deze lijn onder de ..IngegevenKenmerkenTypeApi plaatsen (volgorde zelfde als de args erboven)

terecht, zal er volgende keer rekening mee houden.

Dit is moelijk te reviewen. Is dit enkel een naamwijziging?
Zoja SVN replace
Zonee, naamwijziging apart committen

ok. Maak me hier wel de bedenking omdat dit momenteel overbodig is in deze code. Als het preventief is, dan zouden we dit voor alle methods moeten doorvoeren. En ik kan me voorstellen dat in sommige gevallen je liever een error hebt, dan een lege waarde waardoor de data kan foutlopen ?

Is goed ga ik aanpassen. Het idee hier was duidelijk te maken dat het over oude globals gaat -> zie bijbel omschrijvingen. Het zoeken in code naar "vervref" zal dan iets lastiger worden.

De oorspronkelijke code die deze class gebruikt bevat BonLijn.GeefOrderID() en ik hou het hier graag consistent. Alle andere code refactoren naar Id lijkt me ook geen goed plan.

Dat zou es verder uitgespit moeten worden. De tijdelijke globals worden lokaal opgezet en als ze naar onafteralltests gaan, dan blijven er variabelen open staan. Dus het lijkt erop dat dan ook de opgezetten data (en niet alleen de globalnaam als string) naar de onbeforetest zou moeten, maar die zijn test afhankelijk.

Misschien kan je deze method ook afzonderen in een bepaler, dan kun je in de test duidelijk maken dat de HeeftOrderlijnenOpTransport afhankelijk zijn van het aanwezig zijn van een vervoersreferentie en moet je KUL niet "mocken" in je test

VervRef mag voluit geschreven worden (leest gemakkelijker)

OrderId