On Fri, May 7, 2010 at 11:03 AM, Greg Donald <[email protected]> wrote: > On Fri, May 7, 2010 at 9:46 AM, Marnen Laibow-Koser > <[email protected]> wrote: >> Use what works for you. But don't claim "academic masturbation" in the >> face of many of us who know it not to be true. > > That's been my experience when using them. There's no reason to to > replace what's already there and already works great. Two others help > write the book. I would trust the three of those guys before anyone > who endorses Cucumber, any day of the week.
I'm not a fan of dogmatism on either side. A few observations though: 1) I own every edition of AWDWR, including the latest version covering Rails 3. Each edition is an evolution of its predecessor. It started with test/unit and fixtures since that's what came with Ruby and was baked into rails. Although alternatives have appeared, the book has tended to stay there, probably because a) it's talking about what comes with rails, and b) it's easier not to rewrite sections when you don't have to. There are also pedagogical concerns. AWDWR is primarily an introduction to rails. Just like they teach physics in high school without recourse to calculus, doesn't mean that calculus isn't a very useful tool when you really start to practice Physics, some advanced topics are best left to later courses. 2) Rails 3 has refactored rails so that test/unit isn't closely coupled. If you install the rspec-rails and cucumber plugins, for example the rails3 generators will automatically produce rspec specs and cucumber features. Since the 4th edition of AWDWR is in an early beta form, I don't know how much Sam will cover this. Again, there's a certain amount of inertia. For one thing he has made and effort to bring testing earlier in the depot example, which I like. However he hasn't changed the flow to use test driven design, which is and should be standard practice for rails developers whether they are using test/unit, rspec, shoulda ..., I understand that just breaking up the testing chapter and reshuffling the chapters. It's better but it still comes across as fostering code first then test, which I doubt the authors fully endorse. 3) Fixtures. There are lots of experience Rails developers who have come to the conclusion that fixtures really s*ck. Hence all the fixture replacement plugins. In my experience, these days fixture replacements tend to be used much more than the built-in rails fixtures in real-world rails projects, not that there's much of consensus on which one is best. If fixtures work for you find, if not... 4) RSpec and Cucumber are seen as very powerful tools by a wide range of Rubyists and Rails app developers. Far from spilling our intellectual seeds on the ground, as your colorful characterization would have it, we are being very prolific, thank you! 5) I would argue that the fact that Dave Thomas is the publisher of "The RSpec Book", which really should be called the RSpec and Cucumber book, constitutes an endorsement of RSspec and Cucumber. But then as they say in Rome, de gustibus non est disputandum! Use your intellectual seeds as you will. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
