[rspec-users] State Based vs. Behaviour Based Spec/Testing
dchelimsky at gmail.com
Sat Mar 24 08:19:20 EDT 2007
On 3/24/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> I've notice that a project like Rubinius has both a spec & a test
> directory. Rspec has only a spec directory. Obviously I support
> BDD, but isn't there also a place for state based/verification
BDD is not a tool. BDD is a way of thinking about TDD. BDD *is* TDD,
with focus (not exclusivity) on behaviour. This is what I believe to
be the initial intent of TDD. This doesn't mean that all state testing
is bad. In fact, most of the expectations in rspec are state-based:
actual.should == value, etc.
I think you're confusing Interaction testing with BDD. Interaction
testing is a very important part of BDD, but it is not the sole
purview of BDD. Mocks have been around for a long time. I can't really
think of anything that you can do with rspec that you can't do w/
test/unit and mocha. RSpec just tries to make it easier to focus on
behaviour by using less "testy" words.
> I sometimes sense that I *do* want to practice Test Driven
> Development. That is, I want some assurance that my production code
> will run as intended. But I also want some verification of a bug
> right after I have implemented it.
Many people fix bugs using TDD. When the bug is reported, just start
by writing a failing test that exposes the bug.
Keep in mind that when doing TDD, the nature of the tests change very
quickly. When you write the failing test, your goal is expose a
missing or incorrect behaviour, and use the resulting test to drive
your design. As soon as that test is passing, it changes in nature,
becoming both documentation and a regression test.
> How can one truly get away from state based testing to some degree?
You can't. At least not in my experience.
> Spec's often seem too "high level" to assure the "testing" of the code.
Again, this has to do w/ approach. You can write low level specs just
as you can write high-level tests. The trick is balance, keeping the
focus on behaviour rather than the internal structure of code.
> I know that Test::Unit code will always be brittle. What happens
> when the code is refactored? It is sure to break.
> Does this suggest that Test::Unit code should be written right after
> development is done, covering the internals of the project?
Again, this is a matter of approach, not tooling. Assuming that you
*must* test something internal, there's no reason that you can't do it
with rspec. But if you are testing internals, I'd reflect on that and
ask yourself why it is important to do so. Ask yourself how the
behaviour is going to be different if the internals change. I'll bet
that most (not all) of the time, you'll be able to find ways to
express your "testing" concerns in terms of behaviour. If you can do
that without having to get too far away from the code to do so, you're
better off because you'll have better documentation and less brittle
We should really be talking about specific examples, because there are
some principles here that are either not being recognized or dying to
get out. Feel free to post some.
> BDD specs should be written first, using TDD with Test::Unit for
> verification (as throw-away code)? Or do mock objects solve all of
> these problems?
> The real question is, do you spec'ers think there is any place for a
> testing framework next to a spec'ing framework?
Heretical though this may seem: RSPEC IS A TESTING FRAMEWORK. There, I said it.
Scott - I don't mean to pick on you here. In fact, I thank you for
posting this because a lot has been said during the early phases of
BDD's evolution that is confusing and obviously misleading. And, in
fact, much of this has been said by me as I've been exploring what the
meaning of BDD is ... to me.
I hope that you'll keep posting questions like this as they can only
help us all to clarify things.
> Scott Taylor
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users