ProductieDetailDocument

FYI: Ik vind het zeker oké dat je hier de ##super hebt weggelaten. (de gegenereerde code die daar stond was eigenlijk zelfs niet correct : LadeHoogte is enum en dus niet in MM uitgedrukt )
De impl in deze afgeleide klasse is wel correct.

De implementatie voor "Lengte" hieronder zou ik wel in een private method steken, analoog aan GeefFrontPlaatHoogte()
Zo blijft deze method simpel leesbaar en overzichtelijk. En dan is de scope ook duidelijk, nl. dat Kleur W7 enkel impact heeft op de kenmerk "Lengte, en niet op de "Breedte" van het Front.

copy-paste foutje :
"... kan niet gemaild worden."
(ook al is de conditie altijd false :-P )

Mag gerust ingekort worden naar:
"Test: Zet 0 karakters van korttekst in bold indien TBX"

Idem voor die van TAX hierna.

Ter verduidelijking zou je kunnen werken met 3 lokale variabelen (booleans). Dan kun je iets beschrijvends meegeven aan de method GeefProductDetailLijnen, waardoor degene die na jou komt (of jijzelf als het lang geleden is dat je de code gezien hebt) niet naar die private method moet gaan kijken om te weten waarvoor er booleans worden doorgegeven.

Dit is de assert die er toe doet. Aangezien het hier om stringmanipulatie gaat kun je er best voor proberen zorgen dat ofwel:

• deze zo waarheidsgetrouw mogelijk is door echte kortteksten te gebruiken.
• deze zodanig ineen te steken dat datgene wat getest wordt zo snel en duidelijk mogelijk weergegeven wordt.

Je zou dit, in samenspel met de opmerking over de naamgeving van de test, zo kunnen aanpakken dat je deze kortteksten begint met een kleine nummerreeks, gevolgd door iets beschrijvends. Bv:
"123456789 frontbevestiging Exp T"
Dat zou dan resulteren in:
"123<b>4</b>56<b>7</b>89 frontbevestiging Exp T"
Zo is het direct duidelijk dat karakters 4 en 7 in bold komen te staan bij frontbevestiging Exp T.

Je moet niet testen of het V1 is, want je WEET al dat het V1 is, want je hebt in de setup van de test ervoor gezorgd dat het ZEKER V1 is, dus deze assert mag er overal uit.

"Zet 2 karakters" blijft te algemeen. Je test moet zeggen welke twee karakters, dus bv:
"Test: Zet karakter 4 en 7 van korttekst..."

Naamgeving parameters:
IsV1 i.p.v. IsV1Aanwezig
HeeftFrontBevestiging i.p.v. FrontbevestigingAanwezig

Uitleg:

• We gebruiken elders in de code ook bv IsProbox of IsFlatpackV1. In gedachten zetten we er nog het woord "Verpakking" achter Het woord "Aanwezig" biedt geen meerwaarde.
• Booleans beginnen bij grote voorkeur met "Is" of "Heeft".

Ook bovenstaand codeblok mag wat refactoring ondergaan...
Je checkt 2 keer op HeeftFrontBevestiging, dus daar kun je dan beter eerst een selectie op maken:

If HeeftFrontBevestiging {
    ... Hier dan een genestte If-Else-structuur voor al dan niet FrontbevestigingExandoT
} Else {
    ...
}

P.s.: Geen ElseIf nodig dus, maar als je hem wel gebruikt, dan een grote I alstublieft

Bovenstaand codeblok zou gerefactored moeten worden. Aangezien de helper-methods ook werken met booleans als parameter, hoef je hier geen if-else-structuur te maken. j kunt hier gewoon 2 calls doen en de aangeleverde booleans hieraan meegeven:
Do ProductDetailLijnen.Insert(..GeefProductDetailLijnVerpakking(IsV1Aanwezig)
Do ProductDetailLijnen.Insert(..GeefProductDetailLijnOnderdeel(FrontbevestigingAanwezig, FrontbevestigingExpandoTAanwezig)

Dit moet worden: Do ..ZetBoldKorttekstVoorFrontbevestiging(DetailLijn)

Deze Quit-lijn mag weg hé. Deze method is een procedure, geen functie.

Hier mag een leeg lijntje tussen (tussen dimmekes en logica)

Naamgeving: Misschien beter ZetboldKaraktersInKorttekstVoorFrontbevestiging

Ik zou de variabelenaam nog aanpassen, van EindVanLijstBereikt naar VerdereIteratieIsOnnodig, want hij gaat eigenlijk nooit tot aan het einde van de lijst als het V1 en Frontbevestiging is, maar slechts tot waar het nodig is.