DUnitLite 0.4: bugfixes and Should.ReferTo
Version 0.4 of DUnitLite is available. It fixes a couple of fairly major bugs (noted below) and adds a minor new feature.
Download it here: DUnitLite 0.4
What is DUnitLite?
For those who don’t remember, DUnitLite is my set of add-ons to DUnit to make assertions more readable, in the spirit of NUnit’s Assert.That(...) assertions (originally from NUnitLite). For example:
Specify.That(Foo, Should.Equal(45)); Specify.That(Bar, Should.Not.Equal(45)); Specify.That(Baz, Should.Be.AtLeast(40)); Specify.That(Quux, Should.Be.OfType(TSpecialQuux));
What’s new in 0.4
- BUG: When you used TInsulatedTest (or TSpecification), DUnit was unable to count the number of passing tests — it just reported 0 tests run. Fixed.
- BUG: When you used TInsulatedTest (or TSpecification), the test-suite nodes were labeled “TInsulatedTest” instead of the actual class name. Fixed.
- NEW: Added
Should.ReferTo(...)(reference equality check). Currently only works for objects, not interfaces.
Score one for dogfood
I’m using DUnitLite to write the tests / specifications for Tyler, so I’m quickly running into its bugs and limitations. This is the first time I’ve seriously tried to use DUnitLite in a project (its use of records-with-methods would reliably crash the pre-SR1 Delphi 2006 compiler we had at work at the time, and I never got back to it), so this is the first time I’ve actually noticed these gaping holes.
Fortunately, I wrote DUnitLite, so it’s really easy for me to fix the bugs. Don’t be surprised if you see a few more releases in the near future.
March 25th, 2008 at 6:49 am
One good thing with Assert is the ability to compile with asserts in or out.
How does that work with DUnitLite?
March 25th, 2008 at 8:03 pm
It works the same way as with DUnit (since it’s built on top of DUnit): you don’t ever compile your unit tests into your production app in the first place. So asserted vs. non-asserted doesn’t matter.
At work, we put all of our unit tests into separate units. A unit called
Accounts.paswould have a correspondingAccountTests.pas.AccountTestswill useAccounts, 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!March 26th, 2008 at 5:14 am
I’d like to point out two things:
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
March 26th, 2008 at 7:58 am
I see. I guess I was approaching the subject from a “programming by contract” perspective. I usually put Asserts in primitives to ensure I don’t feed them silly things in the dev.testing.
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);
?
March 26th, 2008 at 7:59 am
(except the assertion exception ><)
NOW I get it
March 26th, 2008 at 9:02 pm
Patrick: Yes, it would be way cooler if you could add implicit operators via class helpers. Alas.
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).