On Thu, Apr 10, 2008 at 9:21 AM, Ashley Moran
<[EMAIL PROTECTED]> wrote:
>
> On 10 Apr 2008, at 17:00, David Chelimsky wrote:
>
> > otooh - having some scenarios logging in using a post and some by
> > poking around under the hood creates an untested logical binding
> > between the post and the poking. This has the same risk associated
> > with it that raises so much concern about mocks without integration
> > tests that don't use mocks.
> >
> > I'm not saying that there should be a visible log-in step in every
> > scenario. I would just use a request (or series of requests) instead
> > of controller.send("current_user=",...).
>
> Recently I've done a load of selenium-based stories and every single
> one had to log in, except the one that checks you can't do anything
> when you are not logged in. There was no way round the login process,
> so I had to put it in. But there were other stories that I couldn't
> do purely through the browser (eg those that needed users created and
> attached to organisations) because not all of the required GUI had not
> been built first*. For these I resorted to database access.
>
> My questions are:
> - is this acceptable as a bootstrapping processes (direct DB creation
> of data until the GUI exists)
I think so. Keep in mind that not every step of every story needs to
be a round-trip request. It's even good to write some stories that
don't make requests at all!
In any test, you need to control the state of the word - the test
fixture. If your test requires a bit of bootstrapping in order to get
there, that's fine. The only thing that matters is that your test
gives you confidence in the behavior you're testing.
> - is this acceptable in the long run, if you write a story that shows
> that the database changes produce the corresponding user-visible
> changes?
I'm not entirely sure what you mean here. But generally if I'm
testing that the user sees something, then I also want to include the
step where they initiate that chain of events.
Pat
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
