And I’ll make a note to check on that DecimalSeparator thing. That never occurred to me (as you noticed). Thanks!

Lars: Yeah, looks like you got it — the difference is in how much information you see when it fails. Sometimes knowing that Foo wasn’t 45 is only half the battle — you want to know what it was! Assert() doesn’t give you that, and neither do DUnit’s most simplistic methods, Check(Boolean) and Fail(). CheckEquals and friends are much preferred because they do give you the better information. So does DUnitLite, but with DUnitLite, your code is easier to read (because things are the right way around).

NOW I get it

But … (playing at devil’s advocate- note that I haven’t really used NUnit or DUnit) …
What is wrong with:

Assert(Foo = 45);
Assert(Bar 45);
Assert(Baz >= 40);
Assert(Quux is TSpecialQuux);

?

1) When DecimalSeparator is set to anything else than “.”, some tests fail

2) Additional implicit operators could be added via a class helper, so Values.pas won’t need changing.
Alas, Delphi doesn’t allow operator overloaders on record helpers (or class helpers for that matter).
(I’m thinking of requesting this in QualityCentral)

Cheers

At work, we put all of our unit tests into separate units. A unit called Accounts.pas would have a corresponding AccountTests.pas. AccountTests will use Accounts, but never the other way around. So none of those test units are ever compiled into our production app, which effectively gets what I think you’re looking for, i.e., the production app isn’t filled with test code.

Then we have a separate project named Tests.dpr. We compile all of our test units into this app (and only this app), and it’s what launches the DUnit test runner. And you’d better believe that all of those tests are compiled in, whether it’s an asserted build or not — if our tests didn’t do anything, it would defeat the whole purpose of having automated tests in the first place!