Comment Search

Wel raar dat er terug de ID wordt opgeroepen -> lijkt mij beter om code te krijgen alla Offerte.ZetHoofding(..OfferteHoofding) ipv het oproepen van de ExterneVerkoopService.ZetOfferteHoofding.

' zou hier toch voor een iets duidelijker variabele gaan ipv van a en b die dan "A" en "B" terugggeven.

Nog beter zou zijn dat je ..Matches.Object of ..Matches.DataTransferObject gebruikt ipv set Matcher = ....

ja, dat hebt ge met een ander zijn code hé

ja, dat hebt ge met een ander zijn code hé

In de toekomst wel eens bekijken om de oplossing iets generieker te maken -> kwestie van niet iedere keer eentje te moeten toevoegen als er een booleanke bij komt

Deze lijnen kunnen buiten de if-else want zijn 2x hetzelfde

Een basisprincipe van Unittesten is dat je een positief en een negatief scenario moet afdekken (in dit geval : een correcte assert en een verwachte exceptie)
Deze test deed dit effectief goed.
Maar door het uitfaseren van Tipon 300 faalt uw test.
Mijn idee is dat je een andere ladediepte zou kiezen (om het positief scenario te behouden), i.p.v. er een verwachte exceptie van te maken. Want nu heb je 2 negatieve scenario's en geen positieve.

Aangezien het fase 1 is is het goed genoeg -> fase 2a zal hopelijk wel ietske beter zijn.

Verzekeren dat er nergens data zit die niet verwijst naar niet GLSv1 als dat zo is deploy klasse maken om die data te corrigeren.

Aha; ik had hem bewust niet in het rijtje van Verwerk-calls gezet met échte verwerking, maar bij de VerwerkVanHoecke, die ook géén echte verwerking heeft.
Wat is onze conventie hiervoor? Eerst alle echte Visitor-Verwerk-methods, en dan alle meer interne methods?

Kweet niet in hoeverre de adres info overeenkomt met de adres info die we gebruiken in de rest de software.

onelineren ofwel het zetten van LeveringInfo dichter bij deze lijn plaatsen.

Niet iets opzetten , ietske anders doen en dan het opgezette gebruiken