Did I just μBDD in NUnit?

 

Have a look at this picture, what do you see?

 

Yup, that’s the old familiar “no frills we mean business and are professional about our testing” looking NUnit GUI. But have a look at the test names, they look like some dynamic-typing loving hippie wrote them! What are they doing in my NUnit!?

The answer is, they’re lending a BDD-like Given/When/Then flavor to our old workhorse, in a way that’s fully compatible and complementary to the standard NUnit model. Does it require magic and fairy-dust? Nope not really, just some creative use of the TestCaseDataSource attribute, the test fixture looks like this:

GWT doesn’t always make sense, but when it do it can lead to some really communicative tests.

If you want the small (~40 lines) source for the Scenario class just leave a comment.

Visual Resharper

I've been using Visual Studio 2010 Beta 2 at home for a while and truly it really rocks. But something has been nagging me, there just seems to be so much stuff borrowed from everyones favourite plugin, Resharper. And I belive I've found the reason. If you take a screenshot of the new logo and reverse the red and blue channels something quite familar appears.

How to reset registry and file permissions.

If you somehow manage to get into trouble with registry or file permissions and feel that the only sane way out would be to reset them. Here's the magic incantation to put into the black box:

secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose

Using NUnit with VS2010 Beta and .NET Framework 4.0

I've been test driving Visual Studio 2010 Beta recently and it comes with, and defaults to, .NET Framework 4.0, exciting stuff all around until you realize that if you target the 4.0 Framework you end up with this when trying to run your tests. Let's call this, less than helpful. Some googling turns up one solution, rebuild NUnit from source. Now while that is a viable solution you should never just go for the first solution that enters your mind. After some pondering I came to think of the metadata storage signature defintion present in all .NET Assemblies and how it actually does contain the desired framework version.

Using your hexeditor of choice (I like XVI32) simply open "nunit.exe" and search for "v2" it should turn up something like the screenshot below:

Notice the "BSJB" just preceding the version string, that's the metadata signature basically telling us we're in the right place. Now change "v2.0.50727" into "v4.0.20506" save and start NUnit. It will now run under the 4.0 framework instead, happily running your tests.

Oh, if you think that't both rebuilding from source, and hacking metadata is maybe not really "the right solution (tm)" you could just configure it instead.

Thinking in context.

There has been som general hubbub about establishing WIP limits in the Kanban community latly, some have gone so far as to claim that it is wasteful. Or more exactly that they are wasteful since if you're mindfull you can see the same bottlenecks without them. And theoretically I think that is true. But this is one of thoose times theory just won't help.

In my, not so humble, oppinion establishing WIP limits helps us the same way a budgets do. It help us set clear priorites and makes us think about our general goals. It also works as a clear leading indicator for when things are getting out of hand. One could make the claim that having a budget is waste, and if you're really disciplined I guess that is a viable option. But for me, it's not that I strictly need it, it's just way simpler than the alternatives.

Twitter via @hiranabe provided this gem: Kuroiwa-san(ex-Toyota mgr) concluded speech by emphasizing "Thinking for yourself in your context" is the heart of Lean

This is another very tangible postive effect of imposing limits, they help us establish context. The heart of lean and agile processes is thinking in context, anything that helps us faster establish context and be present have a great positive impact on the speed of communication. Thereby helping us improve, reflect, adjust and evaluate. That in turn helps us deliver more value faster, and sustain those improvements over time.

Thinking is not the key, thinking about the right stuff is. Establishing context is vital for that.

Ownership, Responsibility and Sharing.

Im a big fan of collective code ownership. This is my attempt to clear up one common point of confusion. Responsibility does not imply ownership. Making everyone responsible for the whole codebase most often fails miserably for the same reasons very few can keep any sufficently large system wholy in their heads. If everyone is responsible, most often nobody or a select few is. My current thinking about this is that people should be responsible for a slice of functionality or a module depending on your circumstances. But they're responsible, they don't own it. Anyone can, and should be encouraged to, change the code. The responsible guardian for that part should monitor changes, clarify conceptual missunderstandings, know his part of the system on a sufficent depth to be able to detect at a structural and conceptual level when duplication is creeping in to other parts of the system. Having responsibility does not mean soly working on that part, it means shepherding it and making sure that peers adhers to agreed conventions.

I've seen tremendous benefits from this, it lets people get really good at one part of the system, giving them both pride and the ability to at a much deeper level draw parallels to other parts during pairing sessions and work on other parts. It avoids the "everyone knows almost nothing about everything"-problem thereby reducing waste due to relearning and rediscovery. It sets expectations and builds team spirit, if we know that someone will be checking our work we tend to take greater care. And noone want to let a team-mate down. Theese effects augument conventional practices like pair programming in a very positive way.

Anti-If Campaing I've Joined!