Almost Grokking BDD - I think

[Lee]

I think I have the basics of BDD down. I understand that they are
behavior driven (thanks, Captain obvious) and according to my
research, specifications are still able to drive design. basically,
that BDD is what you SHOULD be doing if you're doing TDD very well.
(to paraphrase Dave Astels). Also, according to Dave, specifications
are granular. Specifying small pieces of behavior, and this is how it
drives design. My question is, how granular are those specifications?
If my domain expert asks for "As a store keeper, I need to be able to
add a product to the catalog so that people can buy that product",
there's obviously any number of ways to implement that.

Normally, I's have tests that test each step in each layer (IVew gets
input hands it to Presenter, Presenter send the object to repository,
and and integration test for when repository saves the object to a
database). Am I mirroring that kinda flow?

What I am envisioning is the context may be "given a valid product"
with an action of saving the product. Then have a specification for
the IView passing to the Presenter, a spec for Presenter boxing up an
object and sending it to the DAL, and a specification for the DAL to
persist it. But this doesn't feel like what BDD is all about. The USER
didn't ask for any of that MVP stuff. They just want to save a
product. But how do I drive design unless I specify those layer
behaviors myself?

Or do I just write the BDD spec for Should_save_a_product_to_catalog
and then write unit tests to drive design? That doesn't feel right
either.

I feel like I am on the cusp of getting my head around this, if I can
just get past this last part of how to drive the design with
specifications.

Sorry for the length. Any help would be greatly appreciated.

Lee

[Tim Haughton]

Hi Lee,

I usually find that breaking up specs into assertions about partiular states helps. For example, lets say I'm writing a Stack<> class, with the usual push, pop peek and count functionality. I might organise my classes like this

class WhenStackIsEmpty
     spec CountShouldBeZero
     spec PopShouldThrowException

class WhenStackHas3Items
     spec CountShouldBe3
     spec PopShouldReturnLastItemAndReduceCount

And so on. There's an example on my blog here:

http://www.agilemicroisv.com/2008/03/executable-spec.html

Regards,

Tim Haughton
www.agilemicroisv.com

2008/11/26 Lee <leeb...@gmail.com>

[Dean Michael Berris]

Hi Lee,

On Wed, Nov 26, 2008 at 3:37 PM, Lee <leeb...@gmail.com> wrote:
[snip]

>
> Or do I just write the BDD spec for Should_save_a_product_to_catalog
> and then write unit tests to drive design? That doesn't feel right
> either.
>
> I feel like I am on the cusp of getting my head around this, if I can
> just get past this last part of how to drive the design with
> specifications.
>
> Sorry for the length. Any help would be greatly appreciated.
>

I remember having to deal with something like this before, and the way
I go about it is that I have four different layers of tests (or
specifications):

- Acceptance Testing
- System Level Testing
- Integration Testing
- Unit Testing

Now, this may seem like too much testing, but I believe there is no
such thing. ;-)

So for your particular problem, I think you should have acceptance
tests that reflect the expected behavior of the whole solution. You
might write something using an automated testing framework (if it's a
web site, maybe something like Selenium or Watir) to make sure that
you translate the specification into actual tests that look for the
desired behavior.

System level testing will actually test the system at a slightly lower
level. If you require that your solution enforce identities or
sessions, this is the level you test/specify. For instance, if you
require that certain actions be performed through HTTPS, or that
images should be fetched from a different domain, or that pages load
within 1 second of initial request, this is the level you test it at.

Integration testing will specify how components should work and how
individual units should work together. If you want to specify that
Customer objects when registered with a CreditCard object should be
able to perform a purchase. This is where you have *real* objects
dealing with each other, and the behavior specified appropriately at
this level.

Unit tests will specify how each individual unit of functionality
(usually your classes) will be scrutinized -- and their behaviors
specified accordingly (through your tests). For instance, you want to
specify that a Customer object should have specific details when
they're constructed, or that a CreditCard object should have a
valid/conforming card number when you construct one.

I hope this example helps.

Have a good day!

--
Dean Michael C. Berris
Software Engineer, Friendster, Inc.