Comment Search

De ..Enum.VerzendWijze.Parcel e.a. zou de overzichtelijkheid/leesbaarheid van deze methods zeker wel ten goede komen.
t proberen waard ?

Deze class zou beter ge-renamed worden naar Fake of Mock (???)
Dat weet gij beter dan ik

Als iedereen die de SessionManager gebruikt overweg kan met andere Personalities dan "1"

Algemeen casing.

Eventueel deze method opsplitsen in VoegToeIngegevenKenmerken, VoegToeBerekenDatum, VoegToeHalfFab,... kleine methods met duidelijke benamingen.

Bij gebrek aan tests de commentaar updaten (14 = BarcodeWaarde volgens bijbel)

idem testnaam

Een voorstel om linefeeds gebruiken zodat de samenhorende blokken code duidelijker worden of zelfs methods zoals AssertSelectieKenmerk.

DRY Exceptie staat er al in dus het zou eerder GeefDetail moeten zijn , om toch een duidelijk verschil te hebben tussen de string en stream implementatie is er voor GeefDetailStream gekozen

Huidige werking van de logging is zo dat er eigenlijk per te loggen item een nieuwe instantie moet opgevraagd worden.

leverdatum ipv Leverdatum

In het vervolg beter gewoon de data hardcoded te zetten ipv geavanceerde replaces te doen zodat er niet de noodzaak is om naar de data te gaan kijken.

Bij deze test zijn de omschrijvingen steeds dezelfde. Misschien een idee om lijnnummers bij te vermelden. Mocht er een fout optreden, dan weet je op zijn minst het aantal dat goed gaat.

dim mag op 1 lijn met methodcall GeefBonLijn

Volgens ik de code van de logger zie, kan je zonder problemen ##class(vhLib.Logger).%New() hergebruiken en 2x een Error method oproepen zonder problemen. Binnen de klasse is het dezelfde applicatie / groep.

De meegegeven parameter / data wordt ook in deze class meegegeven in de constructor en is dus al gekend en blijft ongewijzigd. Dumper kan dus zonder problemen naar constructor. Voglens mij kan de volledige Dumper...ToStream zelfs in een property gezet worden in de constructor van de klasse. Of kan dit opgelost worden via lazyload ?