re: How To Never Fail At The Fizzbuzz Interview Challenge VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Yes. You can. But will you, really? IMHO alert. In Test-Driven Development, you pass the failing test with the simplest possible solution. And y...
 

For this "Multiples of 15" test, my refactored version would be something like

         "Multiples of 15" {
            forAll(BigInteger.positive()) { nb ->
                fizzbuzz(15 * nb) == "FizzBuzz"
            }
        }

As you can see one small pb was that I was too lazy to lookup how to test for only positive numbers. The harder and much more interesting one is I'm not used to think about integer overflows. This style of testing forced me to think about it because my test kept failing! That was actually a teachable lesson.

Anyway I highly recommend this, most fun presentation about testing I have ever read!

slideshare.net/ScottWlaschin/an-in...

Great refactoring!

Still the "15 * nb" part requires a mental leap.

Example tests are nice because, when written well, they can be read very quickly (like prose).

Another thing. So what if I don't need my code to handle overflows? Because all the numbers that business wants to work with are under 500.

YAGNI in that case.

I've taken a look at the presentation. And I'm still convinced that 2 tests is enough to drive out correct "add" code if you follow 3 rules of TDD.

And if you doubt that I thought about this enough, here is my own presentation about PBT: github.com/waterlink/property-base...

code of conduct - report abuse