New DUnitLite feature: String context

When you’re comparing long strings, DUnitLite 0.2 (download) now shows just the context — the first character that’s actually different, plus 30 characters before and after — instead of the entire string. If there’s only a small difference buried in a really long string, this makes the difference much easier to spot.

Specify.That(Query.Sql.Text, Should.Equal(ExpectedSql));

Expected: ...'.TicketID = Tickets.ID'#13#10'WHERE Component = 42 AND Status = 1 A'...
but was: ...'.TicketID = Tickets.ID'#13#10'WHERE Tickets.Component = 42 AND Tick'...

Ellipses (...) are added at the beginning and/or end to show you when you’re seeing a portion of the value, instead of the whole string.

I’d like to do like NUnit does, and show another line with a little arrow ^ pointing to the first character that’s different. Unfortunately, DUnit’s test-failure output isn’t shown in a fixed-width font, so I wouldn’t have much way to get it to line up.

Download DUnitLite 0.2 and give it a spin, and let me know how this feature works for you. I expect it to take some tuning and tweaking before it works reasonably well in most circumstances, and there’s no better way to know what needs tweaking than to use it in the field.

New DUnitLite syntax: Should.Yield

No, I’m not adding Ruby-style blocks, more’s the pity. Just some syntactic sugar.

SpecifyThatInspecting('', Should.Yield(Apostrophes(2)));
SpecifyThatInspecting('a', Should.Yield(Apostrophe + 'a' + Apostrophe));
SpecifyThatInspecting(#13#10, Should.Yield('#13#10'));

The above samples are from the StringInspectorSpecs unit in DUnitLite. They specify parts of the contract for a method called Inspect, which takes a string and returns a string.

One of the requirements for TStringInspector is that when I call the Inspect method, and pass it #13#10, it should return '#13#10'. In other words,

Specify that inspecting #13#10 should yield '#13#10'.

As you can see, Should.Yield is nothing more than an alias for Should.Equal. Use whichever one makes your code most readable.

This is where I expect a lot of the work will be done with DUnitLite-style specifications: with custom assertion methods like SpecifyThatInspecting. Play with it and see what other readable assertions you can come up with. I’m certainly willing to tweak the framework, to add more things along the lines of Should.Yield, if it makes specifications more readable.

(The version with Should.Yield hasn’t been released as a ZIP yet. You can view StringInspectorSpecs.pas, browse all the latest source, anonymously check out the latest code, or wait for the next release.)

Update: This feature is included in the DUnitLite 0.2 download.

The shopautodotca seocontest anti-meme

Raymond Chen (and if you’re a geek and don’t know who he is yet, you need to read his blog) is participating… sort of… in something called the shopautodotca seocontest.

It’s kind of a spam competition, and he’s participating by being a conscientious objector. Sorta.

From his “shopautodotca seocontest online contest tacitly encourages comment spam” post:

There is a Canadian web site that is running a contest to see who can get their web site to rank highest for the terms “shopautodotca seocontest”. There’s $14,000 in prize money at stake (presumably in Canadian dollars), as well as a contract as the company’s SEO manager. Since the contest rules do not rule out spam as a mechanism for improving search rank, this web site (and no doubt others) are getting hit with comment spam…

This web site has a Google page rank significantly higher than the current contest leader, and I think it would be a nice touch if I, as one of the victims of their antisocial little contest, ended up winning it.

Just figured I’d join in the fray by contributing to Raymond’s page rank for the offending phrase. I think it’d be a riot if he wound up outranking all their spam-contest participants.

Opting out of “pre-approved” credit card offers

Some of you may already know about this, but I didn’t. The Big Three-And-A-Half* credit agencies (Equifax, Experian, TransUnion, and Innovis) have a Web site where you can opt out of being on lists they sell to companies offering “firm offers of credit”, i.e. pre-approved credit-card offers. The opt-out site is at

This is not for general junk mail; this is just for pre-approved offers of credit and insurance. And not even all of those — just the ones that come via mailing lists sold by the big credit agencies. Still, I’ll bite.

Their Web form asks for your Social Security Number, which raised my hackles, but I did some poking around and they seem to be genuine. For example, LifeHacker speaks favorably of their site, and here’s a Wall Street Journal article that talks about them. Pretty good recommendations in my book.

There’s also a phone number: 1-888-567-8688 (1-888-5-OPTOUT). I assume it’s the same deal, with asking for your SSN and all. I used the Web form.

* Sure, everyone’s heard of the Big Three credit agencies, but Innovis? Who the heck is Innovis?

Well, whoever they are, they’ll be selling a little less of my info now…

ReSharper Jedi blog

If you use ReSharper or think you might someday, you owe it to yourself to check out Ilya Ryzhenkov’s ReSharper blog. Ilya is one of the ReSharper developers, and he’s also one of the foremost “ReSharper Jedi” — think power users with light sabers.

I just picked up a sweet trick reading his “Jedi Way — Implementing Members” post: if you’re adding a new method to an interface, you can just go ahead and implement the method right there inside the interface. Of course that won’t compile — you can’t have an implementation inside an interface (what do you think this is, Ruby?) — so ReSharper gives you the expected red squiggly. But it also gives you a red light bulb, and offers to move the method body into the implementing classes! (He has screenshots — scroll to the “Jedi Trick Level 3” section in his post.)

(Note: I haven’t had a chance to try this yet — it may only work in the upcoming ReSharper 3.0. Can anyone confirm whether this is available in current versions?)

Calling .NET code, and hooking events, from Delphi/Win32

A while back, my colleague Sam blogged about our experiences with using a .NET library from Win32. We wound up having to write glue code in managed C++. I recently had occasion to want to link to all three of his posts at once, so here they are.

  1. Exposing .NET code in a DLL via C++
  2. Calling into the C++ DLL from Delphi
  3. Hooking up a Delphi progress event to a .NET object

Note that this code is pretty hairy, but it’s also pretty formulaic. It’s absurd how much code it takes to hook one .NET event from Win32, but if you don’t need events, it’s merely unpleasant.

(Yes, we know about Hydra, but it’s not polished enough for us yet. For example, the way it marshals a Win32 exception into .NET is different from the way it marshals a .NET exception into Win32; one way (I don’t remember which) works great, but the other direction just gets you something like an “External exception” and you lose your original exception message. We haven’t needed it badly enough yet to want to figure out, and work around, all its quirks.)