I would be glad to help in this way, but it will have to be later
today. And instead of using completely made-up code, I'll use some of
my real-world code and tests as an example. I'll gist them later,
unless one of the gurus comes along and provides enlightenment for you!
I was able to get to it sooner than I thought.
http://gist.github.com/338707
This is only one action on a controller. Hopefully it will be enough to
help. I have other code, but it may take too much explanation about the
business process for it to make sense, and that would defeat the purpose
of helping you understand.
It may help you if you try to think in terms of writing the specs first,
before you have any code. After all, that's the point of T/BDD: to write
tests/specs first, then the code that satisfies them. The whole
red/green/refactor process. So when you establish an expectation that a
method will be called, that expectation is satisfied when you have that
code in your application. If you are writing specs to cover existing
code, you don't have the luxury of thinking this way, and that makes it
more difficult.
In the gist, notice the helper methods to simulate someone being logged
in. I'm using stub there because I don't want an expectation of the
methods being called to potentially raise an error. I'll do that
elsewhere. In this case, I just want the methods to be available when
they are needed.
Peace,
Phillip
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
