Wave 1

BDD for Bad*sses

Session Duration: 60 minutes

Session Format: Live Coding w/Commentary

Session Summary:

We all know the basic concepts of Test Driven Development:

* Write the test before you write the code

* Red, Green, Refactor

* Take small steps

* Make it work then make it clean, etc.

But what about the more subtle nuances of test driven design? What about London with mocks and stubs vs traditional Uncle Bobian TDD? How do you decide to drive from the outside vs the inside? What about custom matchers to make tests more expressive? Nested contexts for different sets of examples? Where is the line between BDD and TDD and when should we cross it?

In this live coding session, half the session will be test driving a simple problem using outside-in London style TDD, the other half will start over using inside-out traditional TDD. The focus will be on following the four rules of simple design:

* Software works as intended and you can prove it

* Minimize duplication

* Reveals the intent of the programmer

* Small

Note: This will either be in ruby or javascript; but the principles apply across languages. At the end I'll share libraries for Java/C# that enable these techniques.

Double note: This isn't cucumber. This isn't story/acceptance testing. This is Unit level BDD.


Submitted by

Session Leader Name(s): Zee Spencer

Stage: Accepted

Feedback Score

15 votes

Idea Details

Vote Activity

  1. Upvoted
  2. Upvoted
  3. Upvoted
  4. Upvoted
  5. Upvoted
  6. Upvoted
  7. Upvoted
  8. Upvoted
  9. Upvoted
  10. Upvoted
  11. Upvoted
  12. Upvoted
  13. Upvoted
  14. Upvoted
  15. Upvoted

Similar Ideas [ 2 ]


  1. Status Changed from Active to Accepted
  2. The idea was posted


  1. Comment
    ( Moderator )

    I like that it is specific to unit-level BDD (people do get confused by BDD), it's clear what people will learn. Zee, is it you demo-ing live, or do participants get to fire up their own laptops and code along?

  2. Comment
    Zee Spencer ( Idea Submitter )

    I was planning on live demoing. I've don't have much experience facilitating group exercises.

    Maybe after a couple tries I can figure out a way to do that and achieve the learning outcomes I'm hoping to get.

  3. Comment
    Carlton Nettleton
    ( Moderator )

    I give this a 6 out of 10 (10 being perfect)

    I like that this is a real code exercise and I like that you are giving people two ways to think about the problem - outside-in and inside-out. A good compare-and-contrast of the thought process needed.

    What would have made it perfect is telling me how much time you need. Hard to judge from the description - if you need 90 minutes, then unless you are AWESOME, then I am going to ask you to edit to 60 minutes. Also, I need to get a sense if you have ever done this session before in a public setting. I imagine that you are proficient with these techniques at work, but have you ever got in front of a group and did this? Finally, how do you plan to reach the other types of participants in the room that are not visual learners? How will they persist their learning during, or after they leave, your session?

  4. Comment

    "Where is the line between BDD and TDD and when should we cross it?"

    This could be enlightening. I see much confusion around TDD and BDD as to their purpose.

  5. Comment
    Zee Spencer ( Idea Submitter )


    I generally assume a 60 minute slot;

    I have been doing public speaking, generally 4~5 conferences a year for the past year. For evaluations, please check out http://speakerrate.com/zspencer

    I have done a full dry run on my own machine of this presentation at this time, but have yet to do it at a user group. I intend to do another run at Leandog offices in the next few weeks as well.

    As for non visual learners; I'm clearly stating this is a live coding demonstration. I expect that people will self select out if they do not derive value from a live coding session.

  6. Comment
    Zee Spencer ( Idea Submitter )


    Yea, it's somewhat amusing to me. You can do TDD without BDD, but you cannot do BDD without TDD.

  7. Comment

    Love the practical, technical content and that it's not about the tooling.

Add your comment