Readable behavior-driven tests for DUnit: DUnitLite

DUnitLite (formerly DUnitAssertions*) version 0.1 is now available. (downloads, documentation) It’s open-source (MPL).

DUnitLite is similar to dSpec, except for the placement of parentheses:

// dSpec:
Specify.That(TheAnswer).Should.Equal(42);
// DUnitLite:
Specify.That(TheAnswer, Should.Equal(42));

But I think my approach has a few advantages (which is why I kept working on my version even after I found out about dSpec). As I see it, DUnitLite currently has two things one thing going for it that dSpec doesn’t have:

  • Support for an optional “message” parameter, so that if a test does more than one Specify, you can tell which one it failed on. Just like the optional third parameter to DUnit’s CheckEquals(). dSpec doesn’t currently support this, and it’s not clear (to me) how its syntax could even be extended to support it. Correction: dSpec does support the “message” parameter.

  • Support for enums and records. Okay, “support” is a strong word; you have to write code to support the types you care about — but not much. In DUnit or dSpec, you’d have to write lots of methods to make this work (trust me, I’ve done it many times with DUnit). But in DUnitLite, the duplication has been pulled out. Once you write the code once, the new type is supported everywhere: Specify.That(), Should.Equal(), Should.Not.Equal(), Should.Be.GreaterThan(), Should.Not.Be.Between(), etc. dSpec’s current class structure would make this more work. I think.

There’s also an interesting issue with dSpec’s .Unless() syntax, which can’t be ported to .NET because it relies on a clever deterministic-finalization hack. And if I implemented the same feature in DUnitLite, I think it would work just fine in .NET, just because of the difference in where the parentheses go. But that’s a story for another day, when I haven’t stayed up until after 5:00am trying to release a project.

So anyway. DUnitLite is out there, and it even has a little bit of documentation. It’s an early version (it’s just whatever I had working when I finally got the intellectual-property waiver back from my employer this week), but all of the supported syntax and types should be fully working. Go check it out, and let me know what you think. Enjoy!

* The reason for changing the project’s name is explained in another footnote. “DUnitLite” isn’t that much better, but at least it hasn’t got “Assert” in its name.

Leave a Reply

Your email address will not be published. Required fields are marked *