On 8/31/07, Tom Locke <[EMAIL PROTECTED]> 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:
http://dannorth.net/2007/06/introducing-rbehave.
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.
Cheers,
David
co-Captain
BDDPD
>
> Thanks muchly
>
> -Tom
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
