Test.cls.xml

mag deze dan niet volledig weg?

Ook properties asserten, niet enkel de SVG output (idem voor andere testjes hieronder)

Als je deze apart voorziet, moet je in principe ook eentje voor Stroke, Overflow, ... maken (wat de meest pure manier is als je het TDD-gewijs opbouwt)
Alternatief: breidt de andere test wat uit. Uiteindelijk doe je daar hetzelfde: properties zetten zonder parameters mee te geven.
Je kan in dat geval meer dan 1 ding asserten in een test

Akkoord met Tom.
Maar laten we dit eens tesamen bekijken, hoe we dit best kunnen beter maken, volgens de regels van de (UT)kunst
Mijn idee : Svg.Basis.DomElement moet een abstracte klasse zijn, dus zal niet kunnen ge-newed worden. Daarom een concrete UT-klasse maken die afleidt van DomElement. Daarvan kan je dan wel een UT-SvgObject maken om uw methods te testen.

Wim Vermeulen schrijft uw gedacht ook eens neer ivm het meegeven van values aan de constructor. Sam en ik hebben het er gisteren even over gehad. In theorie is het properder om de constructor enkel objecten mee te geven waarop dependencies zijn. Dan moet elk basisobject natuurlijk wel een "setparams" of "initialize" method krijgen.
Voordeel: testen duidelijker en conform de rest van de nieuwere code
Nadeel: Sam gaat wat door zijn code moeten crossen om het over te zetten (dacht dat het bij het DomElement wel al zo was)

leuk, maar deze test test niets

Als de constructor faalt, zal er wel één of andere exception geraised worden, maar dat is niet het gedrag dat je wil testen in dit geval.

Een test moet na een Assign ook een Act en een Assert hebben, het is dat laatste deel dat gaat vergewissen of de test slaag of niet.

In dit geval zou je bv als assert de volgende lijn kunnen gebruiken:
Do $$$AssertTrue($IsObject(DomElement))

Je moet je natuurlijk de vraag stellen of het zinvol is om enkel de constructor van een object te gaan testen. Als dat een standaardconstructor (dus zonder eigen logica), is dat overkill omdat we er van uitgaan dat Caché er wel in zal slagen om objecten te creëren

Je zou de test zelf bv kunnen vervangen door eentje die een object maakt en dan de nodige setmethods uitvoert en dan tenslotte verifieert dat de gesette waarden ook aanwezig zijn op het gecreëerde object. Dit klopt dan niet 100% met de defaultnaamgeving van onze testen, maar dat maakt nu niet zo veel uit