# [rspec-users] Sufficiently tested?

Zach Dennis zach.dennis at gmail.com
Fri Mar 9 14:59:02 UTC 2012

```On Fri, Mar 9, 2012 at 8:06 AM, U. M. <lists at ruby-forum.com> wrote:
> Hi everybody,

Hello!

>
> I have a general question about how many different cases have to be
> covered in one Example.
>
> Considering the famous Fizzbuzz program, you should test if your output
> is either "Fizz", "buzz", "Fizzbuzz" or just the number (between 1 and
> 100). Pretty simple. However, I often see solutions of testing multiples
> of 3 only by looking at some relevant values like 6, 9 etc.
>
> it "should return 'fizz' when number is divisible by 3" do
>    @fizzbuzz.calculate(3).should == 'fizz'
>    @fizzbuzz.calculate(6).should == 'fizz'
>    @fizzbuzz.calculate(9).should == 'fizz'
> end
>
> So far, so good. But what if I claim that the test will fail in case of
> 12?

Then add an example for this and make that change. I might update the
spec to look like this:

describe "#calculate" do
it "returns 'fizz' when number is divisible by 3"

context "(exceptions to the divisible by 3 rule)" do
it "returns nil when number is 12"
end
end

> It's actually not covered and we are just assuming, that all further
> multiples will work as well, because these do. My idea was to check all
> multiples right away in a loop.
>
> it "should return Fizz if number is divisible only by 3" do
>  (1..100).each do |number|
>    @fizzbuzz.calculate(number).should == "Fizz" if number % 3 == 0 &&
>    number % 5 != 0
>  end
> end

This is more complicated then it needs to be and suffers the same
problem that you are trying to avoid. Here you are testing a larger
data set, but numbers are infinite... so while 100 numbers is more
than 3, it's still a far cry from covering a large amount of the
available set of numbers (which is infinite).

Similar to David, I try to write examples that show the implementation
working, but  once I am confident that the examples I have are proving
that implementation is working then I move on.

>
> Given that the calculate method works fine, both ways will pass. But my
> question is: Does my solution more than it actually needs to or is the
> first one in fact a little too lazy?

What do you think?

Zach
```