Comment Search

OnAfterAllTests() toegevoegd.

Muggenziften en zelf zuchten als ik het schrijf omdat ik het ook niet zou willen doen. Moeten we de relevante klassenamen ook aanpassen? 🙄

Geen idee of het overkill is, maar misschien is het handig als je een lijst of array van VHConfigs ook kan meegeven? Want ik vermoed dat als er iets fout is, dit voor meerder CIDs zal zijn?

Tab na uw datalijnen, en niet na de titels. Zal wel werken, maar is niet consistent

In plaats van commentaar, zou ik dit gewoon in een method plaatsen

string '$X$' kan je in een aparte variabele plaatsen, zodat je geen extra commentaar nodig hebt

Is deze implementatie niet heel gelijkaardig aan die voor MVX? Lijkt mij dat deze in de common klasse kan

Vrij veel code in 1 method, ik zou die wat meer opsplitsen . Ik zie ook geen UT's, dat kan op die manier wel opgelost worden

Hoe dan ook meer en kleinere commits.

• klasse toegevoegd
• filters aangepast
• nieuwe klasse aangesproken
• ...

Kan alleen maar helpen voor als ge iets om zeep helpt tijdens ontwikkeling om te kunnen reverten zonder heel de nest te moeten terugdraaien. Helpt anderen ook om in de commitlog te zien wat er allemaal gebeurd is.Kan ook helpen om een taak die halverwege gestopt is (door andere prio's ofzo) eenvoudig door iemand anders te laten verderzetten.

Soit, iets met gewoontes kweken enzo

Ik zou hier precies ook nog een test schrijven met waarde true voor IsSalesMedewerker.
Kwestie van zeker te zijn dat de waarde niet verloren gaat na encrypt/decrypt.

loglijntje wegschrijven? Of gewoon opeten?

De pxLijn toevoegen kan je best toch conditioneel maken, hé.
Anders

If List.Count() > 0 then pxLijn maken en toevoegen.

Deze lijn staat binnen de For-loop.
Is dat de bedoeling? Volgens mij beter na de loop uitvoeren. Dan toch best effe testen hé

Er zijn geen kleine kartonnen pallet, dit stukje is gewijzigd naar 'Set PalletTekst = "Karton"' (ook verkort sinds die kolom niet zo breed is)

Rollen kan je uit de enum halen

Aangezien de projectSettingsApi via de domeincontext opgehaald wordt, hoeft dit niet...
##class(vhTest.Mock.DOM.common.ProjectSettingsAPI).MockInstance() zorgt hiervoor...

hier ook

Deze method is wel heel lang. Ik zou deze opslitsen en evt ook afgeleide klasses maken voor LBX, MVX en TBX? Op die manier kan al de "MatUitsparingSnijPositieBepaler" afgezonderd worden + extra implementatie voor MVX.

De verwerking van 1 mat / verschillende matten kan ook opgesplitst worden in aparte methods.

Is ook vrij veel logica, dus naar mijn mening best de bestaande UT uitbreiden

Waarom de oude deployklasses wegsmijten? Om niet in in zoekresultaten te komen?

Dit is wel oké. Ik heb de testinput aangepast zodat die compatibel is met Encoway:

Set LbxKenmerken.UitsparingData.UitsparingZ1 = ##class(DOM.PM.enu.UitsparingCode).Smal160()

-> De breedte is steeds 160, waardoor de waarde steeds 1 is:
Set Variabelen("KapZ1") = $Select(BreedteZ1=160:1, 1:2)

Typo: Categor

Kweetet, maar zit op nog veel plekken zo 😅 (ook door mij 😂)

Zelfde opmerking: mij lijkt dat dit eerder in een WSimpl of iets dergelijks hoort