On Mon, Nov 24, 2008 at 2:18 PM, Mark Wilden <[EMAIL PROTECTED]> wrote: > On Mon, Nov 24, 2008 at 10:29 AM, Pat Maddox <[EMAIL PROTECTED]> wrote: >> >> I disagree with the part about edge cases. Acceptance Tests are about >> defining and verifying business value, and edge cases are supremely >> valuable to businesses. What happens when an ATM user tries to withdraw >> $1 more than he has available in his account? > > Withdrawing $1 more than available is an edge case, vulnerable to an > off-by-one error, and doesn't need to be shown to business, in my opinion. > Testing that is a means of detecting errors - it's not a specification. > > What happens when an ATM user tries to withdraw $100 more than available is > not an edge case, and should be shown to business. > > I realize it's a fine point - I'm just responding to whether the business > needs to see what we call "edge cases."
If the customer feels the scenario is important then it will be a scenario. I would not rely on that scenario for exhaustive coverage that withdrawing money from the account worked in all cases. Nor would I go write more scenarios to cover withdrawing $1, $2, $100, etc. T This is where the value of object-level code examples come into play. Features/scenarios are intended to provide clear communication for the behaviour of the system and the value it provides. They are not intended to be exhaustive. Object level code examples (the specs) are intended to be exhaustive. This is where we affect the design and maintainability of the objects in our code. This is where we as developers are disciplined to make sure that we have good examples and regression against withdrawing too much money from an account, and not worrying about other objects in the system unrelated to the behaviour of an Account. Object level code examples and scenarios combined give us a huge amount of confidence in refactoring the system. One without the other drastically reduces this confidence (at least for me). They work best together. I don't see it as a either-or proposition. Well, the only time I see it as either-or is in the case of things that end up like controllers. On a thread not to long ago Pat Maddox mentioned that he stopped writing a lot of controller specs, and he let the scenarios cover them. I agree with Pat, and I have since started doing this where my controller doesn't have logic that is not tested outside of a scenario. This requires discipline to not let things creep into your controller actions or filters, and to ensure your controller is only used to wire together incoming requests with outgoing responses. In this case, writing object level code examples is largely unneeded IMO. However, as soon as some kind of logic is introduced that isn't adequately covered by a scenario, I'm still writing controller specs. my 2 cents, -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
