dto

algemene opmerking over onderstaande tests:
Ze bevinden zich op het randje van 'te lang'. Misschien zou je kunnen overwegen om de setup van de tests (zeker het maken van de mockobjecten, die op het eerste zicht overal dezelfde zijn), in een BeforeOneTest te steken. Alle Verifieers kan je ook in een private method kwijt.
Soit, dit is maar een voorstel hoor. De lijn is soms moeilijk te bepalen. Stukken code herhalen is op zich niet fout hé, zeker als de rest van de (test)method vrij kort is. Het voordeel van er een beetje generieke dingen uit te peuteren is dat de verschillen tussen de overgebleven code duidelijk kunnen opvallen.

typo: Service ipv Serive

Logger injecteren zodat ge in uw tests kunt verifiëren dat ie opgeroepen wordt als er iets is misgegaan.

Bij nakijken van tests gerealiseerd dat dat misschien voor problemen zorgt als er gerethrowed wordt, maar ik weet het niet exact meer.

#dim A As X = ##class(X).%New()
vervangen door
Set A = ##class(X).%New()

Die stijl heeft de voorkeur bij constructie van nieuwe objecten, zeker als ze een lange naam hebben. Stel dat de %New() nog wat parameters nodig heeft, dan is de kans groot dat ze rechts van het scherm vallen, wat de code minder leesbaar maakt.

Deze opmerking kunt ge hieronder nog een paar gebruiken (en misschien in andere klasses ook, zover ben ik nog niet)

weet ge al of het nog nodig is of niet? Indien niet nodig -> wegsmijten

normaalgezien zetten we geen comments in de code. In principe wil dat zeggen dat het niet duidelijk is wat de code doet. Misschien is het beter om de verschillende blokken in de method op te splitsen in private methods en in je main method krijg je dan iets als:

Do ..HaalMarkupOpVoorPersonality
Do ..GeefMessageId
Do ..MaakRequest
... enz enz

Op die manier is de BerekenProductPrijzen-method korter en leesbaarder.
Heeft ook het voordeel dat, bij een mogelijke latere uitbreiding de wijziging vrij gelokaliseerd zit in 1 (private) method die indien nodig eenvoudig in een helperklasse met zijn eigen tests afgezonderd kan worden.

als iets al overerft van TECH.RegisteredObject en je maakt het mockable, mag de TECH.RegisteredObject weg uit de parents-lijst, want TECH.Mockable is zelf een TECH.RegisteredObject

zelfde opmerking: aparte parameter gebruiken, zelfs als ie momenteel gelijk is.

aparte parameter maken voor Orgalux. Kan zijn dat dat nu toevallig gelijk is aan LBX.

Bij de verwachtmethodcall op de WinkelkarServiceMock heb je overal een lege string meegegeven wat op zich niet fout is aangezien deze een default waarde heeft. Andere parameters die voor deze method ook optioneel zijn, worden ingevuld met een random waarde. Mss kan je naar analogie ook hier een RandomIsGeldig meegeven.

Idem opmerking hierboven

Bij voorkeur #dim (mét type), Set wordt ook toegelaten, een tussenvorm zou ik vermijden.

Test die aantoont wat overgenomen wordt ontbreekt

volgens admin kan dat 28 lang zijn dus zou het hier ook op 28