Ok reading some of your older comments on other blogs, and thinking about it some more. Ultimately, I’m making too many trivialities viewable in the code.

My setup methods should be hidden by a useful named factory, and anyone should be able to scan my test instantly and not be distracted by the extra noise going on, further analysis would just involved inspecting the method.

Naming of that factory or object mother would be a key import trick and something I’d have to practice to get right.

I’ll take everyone’s advice here to heart try some experiments in my day to day code and see what I come up with. once I’m done I’ll try and post a beginner focused BDD post.

Thanks for the constructive criticism and I appreciate you dropping by.

My goal with this was to aim for something that could create a decent output while still structuring my tests in a way that I could dive into a rule when I needed to maintain something later. In that so far I’m happy, but I’m more than open to any improvements.

I’m still an eager student with this stuff, would you care to enlighten me further on “scannability”? or can you point me to where I’m off specifically? Maybe a resource i need to read first?

Solubility is not an option in context specification. I don’t find the descriptions above as soluble as they should be. Sure I can read them – they’re readable. But the focus is first on scannability. Don’t force me to have to read what should be scanned.

Context specification is as much about code usability as it is adopting a new kind of testing framework.

Because()
{
user = service.CreateUser();
}

}

public class with_new_user_service : ContextSpec
{
override Context()
{
DoCommonStubbingAndServiceInstantiation();
}
}

public void SetUp()

{
//common stubbing and service instantiation
Context();

Because();

}

public virtual void Context() {}

public virtual void Because() {}

}

and then i’m totally in agreement, nice touch.

public class ContextSpec
{
public void SetUp()
{
Context();
Because();
}

public virtual void Context() {}
public virtual void Because() {}
}

I have done this for a while, but I’m using MSpec now.

I considered and played with using a template for the base setup method when i started doing this. I ended up having the same calls a lot. for example when setting up context that has to be there for most scenarios like return values that are passed on to another method, or the MockRepository.GenerateMock calls over and over again.

Now if you’re suggesting have a base abstract to help remind people to AddContextSpecific behavior I think you’re correct that would help matters out for my team and other future maintainers. I’d still need a base.SetUp() to setup all the normal boring stuff that doesn’t change from test to test.

[SetUp]
public void SetUp()
{
// init common fields …
_sender = …

AddContextSpecificBehavior();
}

public abstract void AddContextSpecificBehavior();

Then each new context would need to implement the AddContextSpecificBehavior method but not be tied to the base.Setup() call, which can be an easy thing to forget to do. The compiler forcing the implementation of the abstract method also is more explicit about how the pattern works.

Updated code to reflect what I was talking about. If you still have comments or suggestions let me know.

thanks again.

Yes I normally do the When for the context, but usually only after the first scenario is baked then the naming is easier. I’ll update it later with the new scenario’s and maybe it’ll be closer to your thinking.

@Paco

Could you give me an example? do you mean like naming the SetUp methods BecauseUserWasAlreadyInTheSystem ?

Good feedback guys I appreciate it.