[Rspec-devel] Rails controller testing/view testing

aslak hellesoy aslak.hellesoy at gmail.com
Sat Jul 8 23:41:17 EDT 2006

On 7/8/06, Luke Redpath <luke at agileevolved.com> wrote:
> > == Integration ==
> > I'd prefer to use in-browser testing using Watir/Sahi/Selenium rather
> > than Rails' integration testing approach. -Even if we could do it with
> > RSpec. -But we should support Rails integration testing with RSpec too
> > - other people might prefer that over in-browser testing.
> Agreed. In fact, I've always found it strange how Rails refers to
> controller tests as "functional" tests when in essence they are unit
> tests for your controllers and that is all.

Probably partly for propaganda reasons, but also a different
understanding of what's the meaning of 'functional'.

> I'd like to be able to
> spec out my controller actions under their various contexts to test
> they work at the code level, which is what I currently do using
> Test::Unit (in a BDD-fashion).

Me too. For Rails apps I try to always flesh out new functionality on
the UI level first. The next natural step is often to translate your
UI 'requirement' into a very behaviour-centric controller spec.
Example: When I POST to create a new record should be created and it
should be rendered in such and such way.

When what I should really worry about is that my controller should
interact with the model and view tier in a such and such way. (Take it
from the model and give it to the view - pun intended).

> When it comes to proper functional/acceptance testing I also agree
> that Watir/Selenium are the better approach to take as you can test
> things such as AJAX and Javascript more easily. I don't think its
> worth rSpec trying to tackle this problem.

Ideally - yes. But the in-browser testing tools still have rathe por
ajax support in that none of them are event-driven but very sequential
in their nature.

> >
> > This looks *very* interesting. In fact, I'd like to explore whether we
> > should support hpricot out of the RSpec box and ditch an
> > assert_tag-equivalent approach altogether.
> >
> > Would you be willing to donate your hpriocot wrapper to RSpec under
> > our BSD licence?
> > I can help integrate it more tightly with the RSpec innards.
> Definately. I chose the MIT license because thats what Rails uses but
> its virtually the same as the BSD license. It would be great to see
> it rolled into rSpec and playing nicely with the should_* expectations.

Great. Do you have any idea whether hpricot will be available as a
binary win32 gem? (There are C extebsions in there). While I don't
have a great deal of sympathy with the win32 community I don't want to
be racist either :-).

Finally, do you have any thoughts on whether you'd like view-only
RSpec support? If so, it would be interesting to see how you'd like
that to look. Any new ideas since you blogged about it?


> Cheers
> Luke
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel

More information about the Rspec-devel mailing list