Hi Guys I'm going to put the cat amongst the pigeons here in the hope of some clarity falling out of the sky on me. My question is this: In a world with Cucumber what is the value of view specs?
In the community (railscamp, for example) there are a fair number of people using Cucumber and skipping view specs, but still speccing controllers, models, tricky view helpers and so on. Why? Because they don't find them helpful. Indeed they are seen as a waste of time (money) not only duplicating Cucumber coverage, but also introducing a high-maintenance example group which designers (who don't run tests) will frequently break. These people aren't stupid. They're producing working apps. I don't claim that their work cycle is perfect: this is about utility and efficiency, or about being lazy or avoiding boredom, if you prefer. I've been working in a mixed environment, with an existing project which uses rspec and cucumber (sans view specs) and my own green field app for a different client. I've been following the BDD approach prescribed by the RSpec book (or so I think). This works, and has produced a lot of LOC. I've not worried, as it has given me plenty of practice with the various arms of rspec, webrat, and other tools. Now that I'm more comfortable with them things are starting to get tiresome, especially duplication, and I'm worried I'm creating a monolith. Too many specs => TLDR ? What should I try using view specs for? Why are they better than cucumber for this? "Driving views through examples helps us think about what the view needs in order for it to do its job. It encourages us to write the code we wish we had to fulfil those needs." I'm not sure how this is any different to what I do in the outer circle with Cucumber. If I write an explicit scenario like http://gist.github.com/221004 then I already know what the view needs to let me do. If I write something more broad-brush (which you will do, if quickly sketching out features during a design meeting) like "When I add a page link" I have to then define that step so it goes red (or, heaven forbid, green). But to write that step definition I have to know how I can interact with the page. This example actually comes from a broad- brush step being expanded in the scenario itself rather than hiding it away in a step definition, but that's a different subject. I'm specifying the page's behaviour in the scenario, or in the step definition. Why duplicate this process with a view spec? I keep coming back to the introduction of chapter 23 in the RSpec book but don't seem to be getting anywhere from it. For the time being I'm going to keep writing view specs, but try to make them lighter and cut some of the dead wood by describing unusual or interesting behaviour rather than all behaviour. I'd love to hear your thoughts. Regards Nick _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
