Schrade.Blog : Behavior Driven Development: Inside-Out vs Outside-In Pattern

Comment on Behavior Driven Development: Inside-Out vs Outside-In Pattern by Kerry Buckley

Fri, 04 May 2007 03:21:35 -0700

I definitely prefer outside-in. A couple of justifications:

The context should represent a state, not an object or method. "A sword" is only a context if you're specifying behaviour for all swords, "A new sword" describes a sword in a certain state, and "sharp?" seems to me to be a programmer-centric way of writing specs (more like an early xUnit approach, where we used to generally write one test per method).
I also like to keep to one assertion per test, so the inside-out example would have to be split into "should return true when the sword is new" and "should return false when the sword is used". This is slightly more expressive than your example, but still seems to describe what the code does, rather than how the object behaves. This might not always be a bad thing, but I don't think it's really BDD.

Comment on Behavior Driven Development: Inside-Out vs Outside-In Pattern by Aslak Hellesøy

Fri, 04 May 2007 04:20:53 -0700

Outside in man. Inside out sounds like after-the-fact testing, missing the point of TDD/BDD.

You can say:

sword.should be_sharp

Trackback from Inforbiomatica: BDD: specifying domain objects de novo on Behavior Driven Development: Inside-Out vs Outside-In Pattern

Sun, 06 May 2007 17:50:56 -0700

The vanilla example used in most blog posts for BDD is some incarnation of de novo domain object specification, that is, specifying the behavior of a simple domain object from scratch. David Chelimsky’s stack example is a decent online examp...

Comment on Behavior Driven Development: Inside-Out vs Outside-In Pattern by Moses Hohman

Sun, 06 May 2007 18:09:51 -0700

One of Kurt's mysterious coworkers here. Another problem with the inside-out approach above is the name of the example, "sharp?", which is pretty meaningless when you see it in the HTML output of a bunch of specs. Funny for me to say that, because I was the guy discussing this with Kurt. I'm not sure if I'm in a camp, but if I am, I wouldn't describe the camps in this way.

I tried to write something about the original example that prompted this discussion, but midpost realized that the method in question (blank?) was only used in one place, in the spec code for a collaborating class, so I thought that was a bad example. So instead I focused on a similar situation in the specification of the behavior of the same class. Hopefully more detail helps clarify things.