From: "David A. Black" Date: 2008-09-11T19:14:10+09:00 Subject: Re: unit testing advice Hi -- On Thu, 11 Sep 2008, David Chelimsky wrote: > On Wed, Sep 10, 2008 at 7:04 PM, David A. Black wrote: >> Hi -- >> >> On Thu, 11 Sep 2008, David Chelimsky wrote: >> >>> On Sat, Aug 23, 2008 at 6:24 PM, David A. Black >>> wrote: >>>> >>>> Hi -- >>>> >>>> On Thu, 14 Aug 2008, David Chelimsky wrote: >>>> >>>>> On Sun, Aug 3, 2008 at 7:20 AM, David A. Black >>>>> wrote: >>>>> >>>>>> The model generation just gives you a file with an empty class >>>>>> definition >>>>>> for >>>>>> your tests, and I think something similar happens with RSpec. (Just to >>>>>> clarify: I'm talking about model generation, not scaffold generation, >>>>>> which does give you all sorts of tests and which I dislike strongly >>>>>> and consider manifestly counter-productive.) >>>>> >>>>> Hi David - I'm curious to know more about why you find this >>>>> counter-productive, if you wouldn't mind sharing. >>>> >>>> Sorry -- I didn't spot this among the unread for some reason. >>>> >>>> I don't want to go into depth since we're not in a Rails forum, but in >>>> brief, it's my experience that the scaffolding neither provides a good >>>> starting point for a production application (which I don't believe it >>>> was ever intended to), nor serves as a good learning tool (which I >>>> believe it is supposed to be). It's a one-trick pony, and there's much >>>> too much of a history of people getting confused or stymied because >>>> they assume that what the scaffolding does is somehow a "default" or >>>> authoritative application skeleton. >>> >>> Hey David, >>> >>> Thanks for the response. And here's my late response to yours for much >>> the same reason... >>> >>> I understood your previous comment to mean you found the code examples >>> generated by rspec to be counter productive, but now I'm sensing its >>> actually the scaffolding. >> >> Yes, I meant the scaffolding. >> >>> Forgetting about rspec or rails, my take is that generated code is >>> just like your own code as far as the ruby runtime is concerned, and >>> that *if* you are using generated code and maintaining it, that it >>> should be accompanied by a robust set of generated tests. >>> >>> Agree? Disagree? >> >> It's an interesting question. I'm trying to puzzle through whether >> there might ever be a case where you'd be generating code but >> generating the tests for it was for some reason prohibitively more >> difficult. I think that if not then it makes sense to generate tests. >> Or do the tests sometimes themselves involve code generation? (Maybe >> just dynamic code generation.) > > I meant the question more generally, but in the case of the rspec > generators, they do generate tests using the same command line > arguments that rails uses generate the application code. So if you > generate a resource with a 'name' attribute, the generated tests for > the new and edit forms expect there to be a form with an input for > 'name'. > > render "/companies/new.html.erb" > > response.should have_tag("form[action=?][method=post]", companies_path) do > with_tag("input#company_name[name=?]", "company[name]") > end > > What's your gut reaction to that? "Too much"? "Oh, cool"? "Ewwwwww"? "Awesome"? I have trouble getting past the concept of "generating a resource", at least as reflected in Rails scaffolding and usage generally; see: http://dablog.rubypal.com/2008/3/23/splitting-hairs-over-resource http://dablog.rubypal.com/2008/4/24/splitting-hairs-over-resource-part-2 Having the test certainly makes sense if you've definitely decided that the generated code is what you want. In this case I think for me the problem is more in the underlying code generation step itself. David -- Rails training from David A. Black and Ruby Power and Light: Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL Advancing with Rails January 19-22 Fort Lauderdale, FL * * Co-taught with Patrick Ewing! See http://www.rubypal.com for details and updates!