[rspec-devel] Rspec Brown Bag

David Chelimsky dchelimsky at gmail.com
Tue Nov 21 00:29:23 EST 2006


On 11/20/06, Brian Takita <brian.takita at gmail.com> wrote:
> Hello,
>
> I'm scheduled to give a rspec brown bag this Wednesday (11/22) for my
> company (Pivotal Computer Systems, http://www.pivotalsf.com). I did see Dave
> Astel's talk as well as several of my coworkers.
> The developers at my workplace are experienced Agile developers.
>
> What would be some good things to focus on for this brown bag?
> Are there slides to presentations that would be useful?
> Any resistance/skepticism, and how to best address these concerns?
>
> I'm kindof nervous because there is some skepticism toward rspec and BDD.
>
> Mainly:
>
> Test::Unit already does that, so why do we need rspec?

The whole context/specify thing makes you see "testing" in a different
way. Sure, you can create multiple test cases to represent different
contexts, but by naming them in text, they become easier to read and
therefore easier to grok.

> It's not production ready. (Stack traces are too cluttered for RspecOnRails;
> although this opinion was based on version 0.6)

To some degree this seems true to me to me. While, with a few
exceptions, the rspec core API is quite stable now, the rails plugin
is quite volatile. For that reason, I think there is some risk to
adopting the rails plugin right now. It really depends on your team
and what the team values are. There is a lot to be gained from early
adoption. You just have to have that mindset.

> New people will be confused seeing rspec code (although this is solved by
> more education, usage, encapsulation, etc.)
> BDD is TDD using "should" instead of "assert"

If all that you know of BDD is rspec, that's an easy misunderstanding
to have. I'd give Dan North's blog a read to help understand the
greater context. In the end it's about language and collaboration
between technical people and non-technical people.

Also, even as a granular, developer practice (absent the wider team
piece), rspec offers clarity in the way you organize your specs (by
context). It offers clarity in the expression of expectations
(actual.should == expected vs assert_equal(:am_i_expected_or_actual,
:am_i_actual_or_expected).

> There are also a number of people who do see benefits to using rspec and are
> excited by it, so I do have "allies". :)
>
> I'm particularly interested in showing:
>
> How BDD is really good TDD without sounding religious
> How rspec encourages developers to create better "tests" than

Focus on your own experience. Do you believe that BDD changes the
conversation? Do you believe that you write better tests (if you MUST
call them that) because rspec encourages you to do so? If so, then try
to tap that. How are they better? Are you writing better code? Are
your designs simpler? Are they easier to change later? Etc, etc. If
the answer to these things is no, then you probably shouldn't be
evangelizing it. That would be dishonest. Just tell people about it
and what your experience is either way (the things you like, the
things you don't). 2 cents.

> Test::UnitThank you,
> Brian Takita
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>


More information about the rspec-devel mailing list