[rspec-users] Spec'ing via features

Zach Dennis zach.dennis at gmail.com
Mon Nov 24 15:01:11 EST 2008


On Mon, Nov 24, 2008 at 2:18 PM, Mark Wilden <mark at mwilden.com> wrote:
> On Mon, Nov 24, 2008 at 10:29 AM, Pat Maddox <pergesu at gmail.com> 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


More information about the rspec-users mailing list