Aaron Mulder on 13 Sep 2007 15:07:08 -0000

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PhillyOnRails] rspec slides

  • From: "Aaron Mulder" <ammulder@alumni.princeton.edu>
  • To: talk@phillyonrails.org
  • Subject: Re: [PhillyOnRails] rspec slides
  • Date: Thu, 13 Sep 2007 11:06:53 -0400
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=p4BoG0rKAAfe1awnM4esvnCVF3JILfy5wPCWC8rwK7c=; b=G+H8flRTm9Cz4Rr/RKoOmBrxmGjNoCgt2w2uxLV8W3Lxf0lejb9eGrAlBnx319PRhz4TtGK+WWCx1LutO4JMhJNUHFwwtQSOGei1by/9vU4W7l7EDbl16f3jxfONObHtpkam7vN4kNyfAyL/9h3yol/iS1vBgyV2P0XiSJ+nA3k=
  • List-archive: <http://lists.phillyonrails.org/pipermail/talk>
  • Reply-to: talk@phillyonrails.org
  • Sender: talk-bounces@phillyonrails.org

It just seems like a tradeoff to me.  The more time you put into
testing, the less time you have for coding, but the more reliable the
code is.  So the question is, for project X, is it better to churn
stuff out quickly and have a harder initial maintenance cycle, or have
a slower development cycle with higher confidence?  Surely the answer
is "it depends..."

To me, far and away the biggest benefit to testing is for detailed
business logic.  I'm not so worried that the Model object won't work
or the Controller won't work or the View won't work...   I'm more
worried that we'll code complex business logic more or less correctly
once, and then someone six months later will make some seemingly minor
change elsewhere that happens to cause inadvertent breakage in the
business logic, and you'd never know it without the tests.

I guess it would be nice to establish a simple pattern for sanity
check tests for each type and then repeat that a lot (maybe with
better script/generate options)...  But I'm not so sure about writing
detailed tests of the frameworky bits.


On 9/13/07, Cassius Rosenthal <cassius@xmodulation.com> wrote:
> Geography prevented me from making it to the RSpec presentation last
> night.  (v_v)
> At MESDA's RubyUG this past August, I gave a 2-hour presentation on
> RSpec.  I used RSpec & BDD to test the Core randomness function using
> the chi-squared test; then I used RSpec & BDD to make the rails app into
> a simple quote CMS that hit up AWS for extra book info.
> I don't have any slides, because I wrote the code during the presentation.
> My conclusion --which I hope Colin will comment on-- is that rSpec has
> many drawbacks, but we should all be using it anyway.  Disadvantages of
> rSpec/BDD:
> * breaks DRY, which is also a Rails convention
> * slows development for experienced coders
> * does not suggest good tests
> * differentiation between 'good' and 'bad' test is not implied by syntax
> * model tests seems solid, but controller tests seem excessive
> (map.resoures.should_not be_trusted =>?), and view tests don't seem
> meaningful
> * trivial changes to schema often will require non-trivial changes to
> model specs
> * doesn't offer integration tests, although you can simulate them --
> documentation suggests using selenium instead of RSpec
> Why we should use it anyway:
> * it is becoming the convention; we must all conform to the conventions,
> or else the power of a convention-based framework weakens, and we all
> suffer; yes, using Rails is like belonging to a commonwealth -- abide
> and enjoy the benefits, or else you justify any retaliation that the
> commonwealth visits upon you.
> (^_^)
> Thanks!
> -Casey
> Colin A. Bartlett wrote:
> > Thanks to all who came out last night for my RSpec presentation.
> >
> > For those that missed it, my slides are online on our blog. (link
> > below) But they probably won't be that useful because they're mostly
> > silly pictures and a few code snippets.
> >
> > Colin
> >
> _______________________________________________
> To unsubscribe or change your settings, visit:
> http://lists.phillyonrails.org/mailman/listinfo/talk
To unsubscribe or change your settings, visit: