impl

Hier gaan toch nog wat testen bij moeten komen, want er is een hele hoop gedrag dat nu niet expliciet getest wordt. De SUT roept één van twee (nog niet) private methods op, maar die hebben op hun beurt weer wat while's en if's zitten. Testen moeten weergeven wat er gebeurt als de while leeg is, wat er in de if en else gebeurt enz enz

BestaatViaFilter en UpdateProductViaFilter zijn dingen voor een repo en horen hier eigenlijk niet te staan (dan kunt ge ze ook proper uitmocken voor de testen)

Deze twee lijnen kunt ge beter vervangen door Quit:ResulSet.HasNext()

kunt ge hier dan niet de ProductInfoInvuller gebruiken? (2x)

naming: een Geef is eigenlijk voor op een repo, maak hier eerder VulInProductInfo van

TECH.Mockable is al een TECH.RegisteredObject, dus die TECH.RegisteredObject mag weg

De standaardnaam voor een testklasse is vhUnitTest.<klassanaam van SUT>.<tetestenmethod>.Test.cls. Dat maakt het veel simpeler voor het geval er meer dan 1 publieke method in de klasse zit.

aan de testen te zien moet deze (en die hierboven) private zijn (want van de andere methods zijn geen testen)

Dus KenmerkGroepenIterator is een Iterator van Repositories als ik het juist volg. Dat komt niet echt overeen met wat in de SUT staat, want daar wordt dat als string beschouwd. Hier zit dus nog 't een en 't ander niet juist

deze GevondenSelectieKenmerken worden nergens anders gebruikt, mag dus weg

KenmerkGroep hernoemen naar KenmerkGroepRepository (want het is een repo, maakt het verderop duidelijker als er kenmerkgroep.kenmerkgroep staat.

en eigenlijk kan je de lijn beter vervangen door een Set ipv een #dim

SelectieKenmerken hernoemen naar SelectieKenmerkenIterator

Naming convention: een Geef geeft 1 object terug (of een exception), een Zoek geeft een Iterator met al niet items erop terug.

Naming convention: een Geef geeft 1 object terug (of een exception), een Zoek geeft een Iterator met al niet items erop terug.
Dit moet dus "ZoekAlleSelectiekenmerken" zijn

Inject ipv Implementation

LegeIterator -> ..EmptyIterator() (en opkuisen hierboven)

zoals aan de telefoon gezegd: deze constructie is vrij tricky.
Bijna alle methods zijn identiek als de parent's impl, enkel de ZoekAlle() verschilt, maar die parameter die meegegeven kan worden, is altijd leeg.
Voor de rest is het enige verschil dat de dataclassname geen class-parameter is, maar ietske dat in de constructor meekomt.
Beter om dat alles via een Factory te laten gebeuren

Aanpassingen hieraan gaan natuurlijk in een hoop andere klasses impact hebben, dus ik ga daar niet overal dingen gaan noteren

opmerkingen hieronder gelden ook voor test hierboven, maar ik ga het geen twee keet intypen