On Sun, Apr 5, 2009 at 10:56 AM, David Chelimsky <dchelim...@gmail.com> wrote:
> What you > describe might be right for your team, but that doesn't mean it's > right for mine. Agreed. > Keep in mind that the more imperative the scenarios are, the more of a > maintenance burden they become. I do work on this code, so I have some idea of the maintenance burden. :) But as I said to Zach, you still have the maintenance burden if you defer this level of detail to view specs. > The scenario I described above could > be run against a set of step definitions that run against a browser, > an API, a desktop app or even a command line shell. We could support > all of those interfaces and not have to change the scenario to do so. > That's a huge amount of flexibility. I am actually not a big fan of "flexibility." It's great if it's free, but I don't find it persuasive in and of itself. I think this aligns with the original principles of XP. I have had projects where a new interface was required at some point. But the vast majority have not. > The tradeoff is that you don't > see the details of the scenarios. For some that is a deal breaker. But > for others, not so much. I was really describing the way I approach scenarios, not prescribing anything for others. I really hate writing view and controller specs, and I've found (so far, at least), that describing user interaction in scenarios obviates them and is better for communication with users. Other people's mileage may certainly vary. ///ark _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
