Joe White’s Blog

When you use a unit-testing framework to compare two records — two TPoints, say, or two TRectangles — would you expect it to stop at the first difference, or show all differences?

Ah, the joys of writing new test-assertion frameworks.

So if I wrote this code:

R1 := Rect(1, 2, 3, 4);
R2 := Rect(2, 3, 4, 5);
Expect.That(R1, Tis.EqualTo(R2));

…what should it output?

It could stop at the first difference, and tell you which one failed:

TRect.Left
Expected: 1
but was: 2

Or it could compare each value separately, and show all the failures:

TRect.Left
Expected: 1
but was: 2

TRect.Top
Expected: 2
but was: 3

TRect.Width
Expected: 3
but was: 4

TRect.Height
Expected: 4
but was: 5

Or maybe it should just show a compact form, and emit one failure:

Expected: Rect(1, 2, 3, 4)
but was: Rect(2, 3, 4, 5)

That last one has the advantage of compactness, but it also loses some context — you don’t exactly have Intellisense in the DUnit output window, to tell you which parameter is which.

Perhaps:

Expected: TRect(Left: 1, Top: 2, Width: 3, Height: 4)
but was: TRect(Left: 2, Top: 3, Width: 4, Height: 5)

But that could get really long, really quickly, if a record had lots of properties. And imagine extending the same thing to classes. Maybe just show the properties that are different?

I don’t know. Which makes the most sense to you guys? Are there other options you can see that might be better?

This entry was posted on Friday, April 13th, 2007 at 6:02 am and is filed under Delphi, Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.