Test.cls.xml

Bij iedere UT moet je denken "Kan deze setup fouten verbergen?" of anders gezegd
"Kan ik een programmeerfout aan het licht brengen, puur door andere input te kiezen?"

Dus de (30, 30) zou je beter aanpassen naar verschillende waarden (zoals bvb. erboven 25,30)

Zoals het er nu staat, kan je enigszins verwarring scheppen tussen de echte MaakLijn() en de VerwachtMethodCall, aangezien deze (eerste) dezelfde parameters hebben.
Bij voorkeur 2 verschillende (dummy) Lijn-objecten gebruiken bij de DanReturn :

DummyLine1 = MaakLijn(0,0,0,0)
DummyLine2 = MaakLijn(0,0,0,0)

AssertClassName bestaat ook

nu die constructor leeg is, kan je je de vraag stellen of hij hier überhaupt nog moet blijven staan.

Een constructie als deze kan een potentieel risico inhouden: aangezien je enkel een Quit $$$OK doet, maskeer je logica die in de constructor van de Superklasses zit. In dit geval is dat niet echt relevant, omdat het toch klasses zijn zonder enige inhoud (bijna). Wou het gewoon even melden.

(logica van de superklasse oproepen: do ##super() )

Sam, deze implementatie gaan we in "pair reviewen" (wss rechtstreeks vanop de code).
We kunnen hier immers vele kanten mee uit

Al opgelost?
Indien niet, dan mag je een "UnimplementedException" throwen (voorbeeldjes via ctrl-shift-find)
Als je echt wil om deze te implementeren, dan kan deze boring best voorgesteld worden door de combinatie van een "interne zijboring" + een "externe zijboring".

Ja, ik geef ook de voorkeur aan nieuwe conventies,
namelijk : While (Iterator.HasNext() ) i.p.v. While ($IsObject(Boring))

Merk op : testen met $$$HasLength() gebruiken we niet (meer) bij objecten, mag alleen nog bij DataTypes, als %String. Voor objecten is het correcter om te testen met $IsObject()

Opm. 2: (naming convention) niet BoringenIterator maar BoringIterator (enkelvoud)

Beter :

 
	#dim sc As %Status

	Set sc = ..TopLine.XMLExport(...)
	Do ##class(TECH.Exceptions.StatusException).ThrowIndienNietOK(sc,"Error bij XmlExport van TopLine bij object "_$this)
	Set sc = ..BottomLine.XMLExport(...)
	Do ##class(TECH.Exceptions.StatusException).ThrowIndienNietOK(sc,"Error bij XmlExport van BottomLine bij object "_$this)

	Quit $$$OK
 

fancy, kende deze syntax eigenlijk niet. ik zou een gewone && gebruikt hebben

Dit wil wel zeggen dat je bij een DoorBoring ook altijd een Zijboring hebt. Klopt dat? (zie BoorType="Z" hierboven)

heb het hieronder al een paar gezegd $$$Not ipv '

$$$Not ipv ' (en pas en passant de casing en spacing efkes aan (if hier en else hieronder)

$$$Not ipv '

en ge moogt dit ineens in een Set steken
Set CrossDiag = ##class(dinges).%New(....)

normaalgezien geen commentlijnen laten staan.
In dit geval wil je de inject blijkbaar niet meer gebruiken. Op zich kan het niet echt kwaad om hem te laten staan, omdat BasisElementFactory toch gedefault binnenkomt in de constructor
Belangrijker: waarom niet meer injecten? Geen testen die daar gebruik van moeten maken? <evil grin>

Do ipv DO

#dim ipv #Dim

Hier (en in andere XMLExport methods) moogt ge gerust een oneliner van maken: Quit ..SvgBox.XMLExport(jadajadajada)

Vraagje voor WV: is het aan te raden om in het kader van 'nieuwe schrijfstijl' hier een BoringenIterator (als OneDimIterator ofzo) op te zetten ipv met de Array te werken, of is dat zeuren over details?

over het opsplitsen van deze lange method hebben we het gisteren ook gehad, dus daar ga ik nu geen epistel over schrijven (maar 't is maar voor het geval dat WV het zou lezen)