[Rspec-devel] Rails controller testing/view testing
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
> > 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
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
> > Luke
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
More information about the Rspec-devel