OptimalisatieBestandenGenerator

Het probleem is dat je hier echt aan het randje zit van wat Windows aankan met de volledige bestandsnaam (247 karakters). Als dit langer is wordt er helemaal geen bestand aangemaakt.

Voor deze IT (BinnenladeLadeKleurW7) heb ik alvast de 006 terug toegevoegd. Dan zijn er in totaal 246 karakters voor de special workshop ImportFile met 100-999 aantal stuks.
Voor de LosseComponenten: volgens mij had deze oorspronkelijk ook geen nummering? Hoe dan ook zou dit in totaal dan 247 karakters zijn met een nummering, toch een beetje gevaarlijk lijkt mij (hoewel nipt mogelijk).

ProductTypeApi en ToeleveringService mogen terug verwijderd worden wegens uiteindelijk niet gebruikt (zie ook verderop).
P.s.: Ook als parameter en als property te verwijderen!

En eveneens niet vergeten de nodige aanpassingen door te voeren in bijhorende testcase: vhUnitTest.APPS.Halux.PPS.Activiteit.impl.TAOR.LijstVerwerkers.Opdeelzaag.OptimalisatieBestandenGenerator.VoerUit.TestProductGroep

Ik mis nog een test met als rol "Front".

Ai, dat is spijtig, dat je hier die "006" hebt weggelaten. Hierdoor staat de W7-specifieke test niet meer proper net onder de niet-W7-specifieke test. Dat zie je overzichtelijk als je deze klasse opzoekt via SVN. Die test-nummering heeft een doel
Hetzelfde geldt tevens ook voor de LosseComponenten-test!

Ik zou "ProductieGroep" niet afkorten in de variabelenaam, hij wordt door deze ingreep al meer dan voldoende ingekort
Dus: ProductieGroepEnum.

Bovenstaande private method BevatBatchProductMetBewerkingInSpecialWorkshop mag verwijderd worden, wegens uiteindelijk toch niet gebruikt (zie ook hogerop)

Property IsSpecialWorkshop mag terug verwijderd worden, want wordt uiteindelijk toch niet gebruikt (zie ook verderop).

Opkuis: Lijn in comment doet niet veel

Bwa, is een beetje zo gegroeid door refactoren...
Waarom een Bepaler new'en per UnitTest, als je hem gewoon 1 keer kunt new'en in een OnBeforeAllTests?
Daarna de afweging: Waarom dan nog de call onder test speciaal gaan afzonderen? En bovendien: Waarom beschikken we anders over een $$$AssertTrue en $$$AssertFalse?
Het was bovendien daardoor ook niet meer nodig om een betekenisvolle, extra lokale variabele te voorzien in de UnitTesten (VerwachtInOpstartfase), dus ook al een regel minder per UT, zonder aan leesbaarheid in te boeten (eerder het tegendeel).
Doe de nieuwe versie eens open in studio en zie eens hoe leesbaar die is
Misschien moeten we dan eerder (mettertijd, als die klassen eens onder change komen) die van LBX en TBX aanpassen naar dit model?

Ik begrijp niet echt waarom je deze "Assert..." method hebt weggewerkt.
Dit is immers een algemeen gebruikt principe, o.a. om aan te geven dat de test-methods in deze klasse dezelfde logica oproepen. Hoe eenvoudig deze ook is.

En voor zover consistentie een argument i : de implementatie bij TAX is nu minder consistent met die van LBX en TBX.

Ik vind dit geen drama, hoor. Als je wilt kunnen we hierover van gedachten wisselen

Kleine suggestie :
OpstartfaseBepaler voor iedere test(method) newen, dat is ietsje properder --> dus in de OnBeforeOneTest() is beter.
Let op: parameter (aTestCase) !