| Cassius Rosenthal on 13 Sep 2007 16:29:00 -0000 |
|
Colin A. Bartlett wrote: Cassius Rosenthal wrote:In RSpec, when faced with a choice between "clever DRY" and "obvious verbose," you are to choose the latter. This is in part because the convention is new, but it's also part of the RSpec philosophy: any other coder should be able to walk in and read the specification, and understand what it should do. This means that you can't tuck logic away somewhere else -- you should repeat it verbosely in every specification that needs it. Repeat yourself often in RSpec.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:How does it break DRY? I don't think the time added is marginal. As Aaron Mulder points out in his comment earlier in this thread, it depends on the project. With multiple coders working over a significant development period, the time added for 'good' specs approaches marginal. With a small number of programmers working on a quick app, experienced coders would do better to just write the implementation, and reserve specs for unusual models and logic. Otherwise they will get caught in copy/past hell, maintaining trivial agreement between the specs and the implementation.* slows development for experienced codersWriting tests may add marginal more time to the initial coding but saves mountains of time squashing bugs later. No -- I'm saying it should "suggest good tests." As people increase their experience with RSpec, their specs should quickly converge in style. I see no such convergence. Instead I see people taking the DSL in many different directions, which indicates to me that it is an incomplete solution. As the DSL ages, conventions in Rails specs may emerge, but they aren't intrinsic to the syntax. Exactly. Would you know one if you saw one? If not, then how do you know when you're done writing them? If so, then why doesn't the syntax discourage writing them in the first place?* differentiation between 'good' and 'bad' test is not implied by syntaxNot sure I follow. What's a bad test? A test (spec, really) that just test's ActiveRecord functions is lame because ActiveRecord is already heavily tested. Other then that, what is there?For starters, I would add any specs that test a function or convention of Rails, like resources. The generator defaults to heavy testing of restful routes, which I think is a waste. Again, it depends more on your situation than on the business logic. [I know you're using a hypothetical, but I would never check for @credit_cards.display_all in a view spec because that implies that you've stuck view info in your model.] If you are specing what the view should look like, then you really want to be testing CSS and DOM stuff, not just html element order, which can change very easily regardless of business logic. Imagine this:* model tests seems solid, but controller tests seem excessive (map.resoures.should_not be_trusted =>?), and view tests don't seem meaningfulI've got no problems with controller tests. And you don't need to spec you entire view. Just the stuff that's business-relevant. How about a test that makes sure @credit_cards.display_all isn't run unless you're logged in as an Admin? Or, don't spec your views at all. Some specs is better then no specs. response.should have_tag('div#flash_notice') do with_tag('p').should be_visible with_tag('p').should be_floating_left with_tag('p').should have_1px_margin end That would be more useful in a view spec. But RSpec might also just not be a good solution for view specifications. From a graphic designer's point of view, a style guide for an online application can run hundreds of pages. While it might be cool to write RSpecs that tested all of the necessary design rules (view specs), RSpec is far too rigid for the way view specing is currently done: the human eye is much better at zeroing in on glaring aberrations, and a marginally trained eye can pick up the details. Controller specs should test whether or not data is available to the view. The more that I think about it, the more view specs don't seem like a good match to RSpec for the general case. I'm talking about a trivial change to make, not a trifling treatment of data. Two weeks into development, the business logic changes and you have to add a valid email to your user accounts. Now you have to add valid email data to all of your specs that test the User model, because otherwise all of those tests will fail. Of course, if you have been verbose instead of DRY as the RSpec philosophy recommends, then you are going to have several find/replaces on your hands. Now stub the email in all of your controller and view specs as well. It adds up quickly. But the reason that we turned to Rails in the first place is that adding the email to the user model only takes 1 migration and one line in user.rb. Now we have much more work to do in the specs on top of that original simplicity.* trivial changes to schema often will require non-trivial changes to model specsI'm not sure that's true. But trivial changes to a schema can kill your app. Dead app = unhappy client. Accurate specs = Happy client. I haven't tried that [or rbehave] yet either, but the RSpec doc still recommends watir or selenium for integration testing, which I suspect it will continue to recommend for a little while. But Rails is a web app framework: integration testing is what we should want most from a specing complement.* doesn't offer integration tests, although you can simulate them -- documentation suggests using selenium instead of RSpecIt's got 'em now. Haven't tried it but Story Runner sounds cool: http://evang.eli.st/blog/2007/9/1/user-stories-with-rspec-s-story-runner Thanks! -Casey _______________________________________________ To unsubscribe or change your settings, visit: http://lists.phillyonrails.org/mailman/listinfo/talk
|
|