[rspec-users] Sufficiently tested?

Zach Dennis
2012-03-09T14:59:02Z

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