Dude, where is my Kaizen?

Björn Rochel's weblog

I’ve just upgraded the trunk to the final 1.5 version of xUnit released last week. This update now allows BDDExtensions to be used with the latest version independant resharper runner for xUnit from xunitcontrib.
Current Version is 1.0.1.16. You can download it here or get the latest sources from the trunk.
Happy specifying . . .

xUnit.BDDExtensions now uses Rhino.Mocks 3.6 internally. I’ve just updated the trunk. As usual you
can find it here: http://xunitbddextensions.googlecode.com/svn/trunk/

Today I received a really nice feature for xUnit.BDDExtensions from a former colleague and friend of mine. It came to me completely with a spec demonstrating and documenting its usage. Completely awesome. I wish day to day software development would always be like that.

The feature deals with chained properties on interfaces. Consider [...]

Earlier the day I wrote about my recent experience with ILMerge. As it turns out there were still some Rhino.Mocks related types which had to be excluded (The ones related to the WhenToldTo / WasToldTo functionality). This issue should be fixed now with my last check-in.
Damn it

Over the past days I finally managed to spend some time with xUnit.BDDExtensions. I can’t possibly describe how good coming back to xUnit.net feels after working with MSTest in my last project. The speed, the extensibility model.  It’s simply not comparable. MSTest is certainly a great tool in case you haven’t worked with a unit [...]

This post by Sean Feldman was kind of an eye opener to me. It introduced me to a feature of Rhino.Mocks I wasn’t really aware of and helped to solve a problem I was never able to solve in a really satisfying way.

As you might know xUnit.BDDExtensions is using Rhino.Mocks behind the scenes, but [...]

public class when_an_automatically_resolved_instance_with_a_single_dependency_is_used_in_a_fixture :
InstanceContextSpecification<ClassWithSingleDependency>
{
private object actualResult;
private IDependency dependency;
private object expectedResult;

protected override void EstablishContext()
{
expectedResult = new object();
dependency = AutoDependency<IDependency>();
dependency.WhenToldTo(x => x.Invoke()).Return(expectedResult);
}

protected override void Because()
{
actualResult = Sut.Invoke();
}

[Observation]
public void should_be_able_to_verify_calls_made_to_the_dependency()
{
dependency.WasToldTo(x => x.Invoke());
}

[Observation]
public void should_execute_the_configured_behavior_on_the_dependency()
{
actualResult.ShouldBeEqualTo(expectedResult);
}
}

This little feature was added to the trunk today. Yes, no CreateSut() call. You can omit it for most of the simple scenarios. You can [...]

What’s the importance of Should in BDD? Why isn’t it called Must, Need to or Will?  It’s one of those subtle psychological things . . .
The main reason Dan North decided to use Should instead of all other  possibilities is, that Should implies that you can always question the behavior of your system. It isn’t [...]

Last week I had a little discussion on the german ALT.net mailing list in which I commented on a code example of a spec that wording in a BDD spec is of vital importance to BDD and therefore should be chosen very carefully. With this post I would like to clarify a bit what I [...]

I’ve been doing BDD with the “context/specificationt”- style for about 4 months now. Examples for this style are MSpec, NSpec or my little framework called xUnit.BDDExtensions.
What bothers me lately is that this style mixes context and behavior under test into one fixture class name, which can be extremely long because of that. An [...]