[rspec-users] Testing for confidence - is this a spec at all?

David Chelimsky dchelimsky at gmail.com
Fri Aug 31 10:24:53 EDT 2007

On 8/31/07, Tom Locke <tom at hobocentral.net> wrote:
> Hi BDDers
> Quick background: I'm working on the Hobo plugin for Rails which,
> amongst many things, automates a great deal of controller code for you.
> Hobo has a built in security mechanism, and the generic controller
> uses this to ensure that POSTs and PUTs only change the DB in ways
> you've permitted.
> I'm writing some rspec examples that test for holes in this security
> mechanism. My feeling is that this really is testing rather than
> specifying. I don't want to use mocks/stubs because I want to be
> absolutely sure that changes have not happened to the DB.
> For example, with stubs, I might say "Post.save should not be
> called", but there are other paths through AR that can result in that
> post being inserted into the DB. So I really want to say
>    Post.find_by_title("test post").should == nil
> (where Post is the real thing, not a mock/stub)
> And my questions are.....
> This is clearly not a spec as such, or a unit test. What is it? A
> functional test? An integration test?
> Where then does it belong?
> Should I be using rspec at all? (I want to because I spec other parts
> of Hobo and the whole rspec environment is step up and ready to go)
> (Note that I don't have any problems here as such - I'm writing these
> tests in rspec style and it's all working fine. I'm just fearful of
> what the BDDPD might say if they catch me! Well really I'm just
> curious as to what "good form" would be)

The subject of this thread says it all: 'testing for confidence'.
That's what all of this is about. It's all about YOU, the developer,
feeling confidence to take the next step. Driving with examples, if
done with discipline, means you automatically get 100% code coverage.
That gives you a lot of confidence to make a change, because you're
sure to get feedback if you screw it up.

Since these have a different feel in your mind, I'd certainly consider
moving them to their own directory. You might consider the new Story
Runner (trunk only, so far), that is designed to be more customer
facing and in direct support of requirements, running things end to
end (no mocks). The Story Runner comes from RBehave - so you can see
what it looks like here:

If you were doing a BDD project (kind of like an XP project), you'd
have User Stories that say specific things about security, and you'd
represent them in Story Runner. Then you'd deal with the individual
objects using the Example Runner (i.e. describe it). In that world,
you'd use mocks to isolate things. Although, even that tends to be
abused. The most visible model is Rails, which couples everything
together so much that you have to use mock models to avoid hitting the
DB from your view specs. But in non-rails projects, it's quite common
for mocks to appear and disappear in process - using them as discovery
tools, but then using the real objects as they appear. You can read
more about that at http://mockobjects.com.

Hope this all helps.


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

More information about the rspec-users mailing list