[rspec-users] State Based vs. Behaviour Based Spec/Testing

David Chelimsky dchelimsky at gmail.com
Sun Mar 25 06:59:12 EDT 2007

On 3/25/07, Pat Maddox <pergesu at gmail.com> wrote:
> On 3/24/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> > 1.  Should you test protected and private methods in your specs?
> No.  You're specifying the behavior of an object as seen by the
> outside world.  Of course protected and private methods aren't
> available to the world, so why would you need to test them?  When
> you're doing state-based testing, just call a method and then verify
> that it returns the expected value or leaves your object in an
> expected state.

+1. Well said.

> > 2.  Should you ever test that a certain instance variable gets set in
> > a method, or only that methods return their correct values?  This
> > question can be generalized to: Should you ever test/spec *parts* of
> > a method?
> Same thinking behind my answer to (1) applies here.

+1 again.

> > 3.  If you already have a code base (with no specs/tests) is there
> > any advantage over using Rspec to Test::Unit for verification testing?
> Sure.
> my_object.foo.should == 3
> vs
> assert_equal 3, my_object.foo
> my_object.should_not be_nil
> vs
> assert !my_object.nil?
> my_object.should have(2).errors
> vs
> assert_equal 2, my_object.errors.size

I think Scott's question was the reverse of what you're answering - I
read "does Test::Unit hold any advantage over RSpec for post-code
verification testing"

Even when I'm doing TDD, once I'm convinced that I've satisfied the
behavioural requirements (typically by passing Acceptance Tests), I'll
review the tests from the perspective of documentation. Can another
developer read these tests and understand how to use the objects being
described? If not, I'll refactor the tests, which may mean adding new
ones. Perhaps there's even a corner case that I haven't covered that I
perceive covering would add some value. In this case, I'll often add a
new test method to cover that, just for the documentation value. If it
passes right away, I'll usually go into the code and tweak something
to make it fail, and then tweak it back. This provides a sanity check
that the test is actually interacting with the parts of the system it
claims to, which is the main reason for starting with failing tests
when you are in TDD mode.

> Ultimately it comes down to personal preference.  If you're doing
> things the right way, you're going to do basically the same thing in
> RSpec or Test::Unit, just with a different syntax.  However if you're
> like me, RSpec makes it easier to do things the right way (or at least
> get close :)

I'm really glad to see that you're having that experience. This is the
whole point of BDD. If you look at the things that Dave Astels and Dan
North have written about since the earliest days of BDD, it is about
making it easier to learn and then practice TDD as we believe it to be
intended by evolving language and frameworks that focus on observable


> Pat
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list