DomElement.cls.xml

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.

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