One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
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!
For this "Multiples of 15" test, my refactored version would be something like
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...