Lots of people asking about Evil FizzBuzz. So here are the instructions: (1/)
First, this is intended as an exercise in combining TDD with Continuous Integration (i.e, Continuous Delivery - not breaking the build!) (2/)
You need a group of at least 5 developers. Depending on how many people, they can code alone, in pairs, or threes. But they will all be working on the same solution as a team. (3/)
The probem they need to solve is to deliver a working demonstrable program (not just a library with unit tests), with the following requirements: (4/)
1. Generate a list of integers from 1-100
2. Numbers that are divisible by 3, replace with "Fizz"
3. Numbers that are divisible by 5, replace with "Buzz"
4. Numbers that are divisibele by 3 & 5, replace with "FizzBuzz"
5. Output this list as a single comma-delimited string (5/)
2. Numbers that are divisible by 3, replace with "Fizz"
3. Numbers that are divisible by 5, replace with "Buzz"
4. Numbers that are divisibele by 3 & 5, replace with "FizzBuzz"
5. Output this list as a single comma-delimited string (5/)
The final acceptance test is that can you show a "customer" a working program that outpts the completed, fizzbuzzed string: i.e., "1,2,Fizz,4,Buzz,Fizz,7,8,Fizz,Buzz,11,Fizz,13,14,FizzBuzz,..." etc. (6/)
It's a team exercise, and you will need to collaborate a great deal and make decisions together about tech stack, tools, design, etc. BUT... (7/)
Each person/pair is assigned ONE of the 5 requirements and must ONLY work on the code necessary for that specific requirement. So, talking, whiteboarding etc is fine. But you can only write code for your specific part of the problem. OK? (8/)
The group must get up and running with version control (e.g., Github) and - very importantly - MUST set up a CI solution that's visible to the whole team and the "customer". Because this is a CI exercise, remember? (9/)
If you have a data projector or big TV in the room, bring up the build status page on that, so everyone can see. (10/)
Once you have a working (green) build on a skeleton solution (i.e., one that compiles and runs at least one dummy test), the build must not go red. This is an exercise on delivering as a team WITHOUT BREAKING THE BUILD. OK? If the build goes red again, the exercise is over. (11/)
The team has 1 hour to deliver a working solution they can demonstrate to the "customer" (12/12)
I love watching groups tackle this challenge. It exercises skills most katas don't reach. It's harder than it sounds :)
