VKP

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.

Bewerkingen met "K||" laten lopen via klasse DOM.PARTIJ.impl.LegacyPartijAPI

ok, er komen no wat wijzigingen aan, ik neem deze mee in de volgende aanpassingen en sluit deze.

Ook bij update worden nieuwe documentreferenties aangemaakt en in de plaats van de oude bewaard, zonder de oude te verwijderen.
indien er al zijn, deze aanpassen bij update.

zou False terug moeten geven. DanDoeNiks interpreteer ik als het resultaat kan me niet schelen, maar hier maakt het wel degelijk uit.
Ook voor volgende tests