The story about TypeMock.

To mock or not. That's the question. Here's how I think some BDDers and Mockists labled their Kool-Aid before drinking it.

Given TypeMock
When I want to test
Then everything looks like a mock object.

Take your system for a SWiM

Marcus Ahnve voiced some intresting thoughts about 'should' and BDD in his post "Words dont come easy: MoSCov and BDD". Here's a few follow-up thoughts.

Since we write tests mainly for two reasons, to validate that we built something right, and often even more important, that we built the right thing. We often seek answers along the lines of, how does this class or compononent work? How do I use it? What precondition must be fullfilled? In short, we want answers.

I propse we learn our tests to SWiM!

S(hould)

The SUT should do something, the core of BDD. "The index page SHOULD have the title...". Great for starting conversations, discussion friendly since it's a quite soft expression that's easy to question with a simple "should it really?".

W(on't)

The SUT simply shouldn't do this. "Reading the same item twice WON'T cause multiple database calls." Good for thoose "Should not" moments.

i(nstruct)

How do I use this component? Learning tests, code samples and the like qualify. Capturing small scenarios as tests can be a nice way to spread knowledge on how to use the SUT, show best practice's and document often raised questions.

M(ust)

The SUT must always do this, "Authentication MUST fail if given the wrong username and password".

As Marcus points out in his comments "BDD is all about conversation" good conversations need strong and shared vocabularies.