[Rspec-devel] Rails controller testing/view testing

aslak hellesoy aslak.hellesoy at gmail.com
Sat Jul 8 23:43:40 EDT 2006


On 7/8/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> 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.
>

Of course, Rails' integration testing doesn't even try to deal with
any of the javascript behaviour and it probably never will. I still
thinks that RSpec should show how it's done if it can be done easily
(maybe with the new inheritance support).

> > >
> > > 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,
> Aslak
>
> > 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