Gelieve de bewuste id in de foutmelding op te nemen en indien mogelijk ook welke type bericht het dan wel was, kwestie om zo duidelijk mogelijke foutmelding te kunnen geven. ps : Enkel eigennamen of het begin van een zin begint met een hoofdletter
Lijkt mij beter om VerzendData uit te breiden met BevatFout en Foutmelding zodoende er maar één object moet doorgegeven worden. Idem dito voor de CancelContainer..
Gelieve het gedrag en het gewenste resultaat iets duidelijk in de test te vermelden zodoende er kan gecontroleerd worden dat de test setup wel is volgens het vooropgestelde gedrag. De volgende stap is dat dat de code voldoet aan het vooropgesteld gedrag van de test.
GeefVerzendData zegt weinig over de wat voor verzend data het is ? Als het echt niet uitmaakt gelieve dan een ##class(vhTest.Dummy) te gebruiken als het wel van belang is gelieve dan een iets duidelijkere benaming te kiezen.
Ik zou toch opteren voor andere data zodoende er een verschil tussen de GLSParcelNumber als de GLSUnitNumber zodat we zeker zijn we het juiste veld overgekopieerd hebben. Idem dito voor de TrackAndTraceUrlVoorKlant en dienen voor VH
Is het niet nodig om het gedrag van deze method te verduidelijken dmv een paar testjes? Of door op te nemen in reeds bestaande tests? En ja, ik weet dat het een lokale (private) method is en dat ge unittests schrijft en geen methodtests en jadajadajada, maar voor een leek zoals ik is het niet onmiddellijk duidelijk hoe het gewijzigde gedrag het probleem zoals omschreven in de titel oplost. Voilà.
Spijtig dat we altijd zoveel testfiles wijzigen, zouden beter systeem moeten hebben om er minder afhankelijk van te worden. De unittest in deze commit is al een stapje in de goede richting.
Niet alle commits van ICT242 zijn opgenomen : 'k weet het - kzou de SVN repo hier ook moeten aan toevoegen ofwel die code in de common steken ben er nog niet 100% wat hier mee te doen. Geen testen ==> needs resolution -> De testen zitten dus in de svn-repo
ik heb een sterke voorkeur om deze berekening af te zonderen, om verschillende redenen. ik denk vooral aan de methods : LBX.GeefUitsparingCode() en LBX.GeefRugwandMateriaal() Graag effe bespreken met WV.
Ook een property MailReplyTo bijvoegen (omdat de meeste mails vanuit de server verstuurd worden) Dit principe moeten we meer en meer gaan gebruiken, om te vermijden dat de replies naar "CacheAdmin@..." worden gestuurd.
Classification:
Not conforming to standards
Ranking:
Minor
Het "Resultaat" vind ik nogal kort door de bocht :
Technisch beschouwd : Het resultaat van "Render" is een pdf-stream Het resultaat van RenderAndFile is een bestand (of een error) --> ObjResultaat.BestandVolledigeNaam en ObjResultaat.ErrorMessage Het resultaat van RenderAndMail is een OK of een error --> ObjResultaat.ErrorMessage Het resultaat van RenderAndPrint is een OK of een error --> ObjResultaat.ErrorMessage
Conclusie: ook al is "RenderAndFile" voorlopig de enige die resultaat MET inhoud teruggeeft, toch zou ik het result-object dus specifiek benoemen, iets zoals hierboven, eerder dan RenderResultaat.DocNaam
Twee belangrijke opmerkingen (dit is de vhisie van WV en JCL):
input params zijn enerzijds te beperkt en anderzijds te specifiek : "MailOpdracht" -> beter een algemene "Opdracht" met ook "Render-opties" object [ Te bespreken met WV/JCL]
OrderData is OK, maar de structuur moet een "propere" dto zijn die AX moet invullen, en wij zullen er in caché dan wel de bizarre "pxMemo"-structuur (e.d.) van maken Let wel: VH legt de propere structuur vast (eventueel met overleg met ADU)
Zelfde opmerking geldt uiteraard voor Offerte- en LeveringService.
In dit soort unittest steeds een positieve case en een negatieve case behouden (dit is een algemene regel) Hier komt dit neer op : minstens één testmethod ZONDER exceptie en één MET exceptie.
Ge moet in deze test niks meer aanpassen, aangezien TIPON volledig uitgefaseerd wordt. dus : Review OK