Test Driven Development specifies that you write a failing unit test before you write any code. Some people say this is impossible. I'll demonstrate that it's not only possible, but will change how you write code for the better.

1. Put the Tests before the
Code: Coding the Right Way
Mike Clement
@mdclement
mike@softwareontheside.com
http://blog.softwareontheside.com
http://agilecodegames.com

2. REQUIREMENTS
You will need these files(Windows) to complete the assignment. Details for method constraints are found in these
documents and are still a part of the requirements. (If you downloaded the test driver documents before 8/30
12:00pm you will need to re-download them. An error was fixed.)
Part 1 - Construct the Arena (5 points)
Extend the ArenaInterface provided; the arena is simply a collection of fighters, each with a unique name
For Part 1 only, you may assume all strings passed to the arena's adding method will be of the correct format
For Part 1 only, you may assume all strings passed to the arena's getting and removing methods will be names
already existing in the arena
Part 2 - Let the Battle Begin (8 points)
Extend the FighterInterface provided; details about abilities, stats, and more can be found in the FighterInterface
For Part 3, the test driver will not call your useAbility() or regenerate() methods, so it is possible to receive credit for
Part 3 without these methods being complete
Completion of Part 1 is required to submit Part 2
Part 3 - Fortify the Walls (5 points)
Make adding new fighters to your arena bullet-proof
This involves rejecting any string that is not of the correct format or that would add a duplicate name to the arena
Make getting and removing existing fighters in your arena bullet-proof
Completion of Part 1 is required to submit Part 3
Part 4 - Let Me Show You My True Form... (12 points, 4 points per fighter type)
Add functionality to the useAbility() method and the regenerate() method for each fighter type
The isSimplified() method must return false for each fighter type to be tested to alert the test driver that full testing
should occur for that fighter type
Completion of Part 1 is required to submit Part 4

3. Clean Code that Works

4. Plan
Requirements
Design
Coding
Testing
Release

5. Design
Coding
Testing

7. Plan
Requirements
Design
Coding
Testing
Release

10. Design
Coding
Testing

11. When you actually sit
down to write some code,
you learn things that you
didn’t get from thinking
about them in modeling
terms…there is a feedback
process there that you can
only really get at from
executing some things and
seeing what works
- Martin Fowler

12. Sample Input
6
1 2
1 3
3 4
3 5
4 6
5 6
2 3
2 4
0 0
4
2 3
3 4
5 1
1 6
7 8
8 9
2 5
5 7
3 1
1 8
4 6
6 9
0 0
Sample Output
CASE 1:
1 2 3 4 6
1 2 3 5 6
1 2 4 3 5 6
1 2 4 6
1 3 2 4 6
1 3 4 6
1 3 5 6
There are 7 routes from the firestation to streetcorner 6.
CASE 2:
1 3 2 5 7 8 9 6 4
1 3 4
1 5 2 3 4
1 5 7 8 9 6 4
1 6 4
1 6 9 8 7 5 2 3 4
1 8 7 5 2 3 4
1 8 9 6 4
There are 8 routes from the firestation to streetcorner 4.

13. Unit tests

14. Fail
Pass

17. Is there more?
How do you know when you’re done?

18. Sample Input
6
1 2
1 3
3 4
3 5
4 6
5 6
2 3
2 4
0 0
4
2 3
3 4
5 1
1 6
7 8
8 9
2 5
5 7
3 1
1 8
4 6
6 9
0 0
Sample Output
CASE 1:
1 2 3 4 6
1 2 3 5 6
1 2 4 3 5 6
1 2 4 6
1 3 2 4 6
1 3 4 6
1 3 5 6
There are 7 routes from the firestation to streetcorner 6.
CASE 2:
1 3 2 5 7 8 9 6 4
1 3 4
1 5 2 3 4
1 5 7 8 9 6 4
1 6 4
1 6 9 8 7 5 2 3 4
1 8 7 5 2 3 4
1 8 9 6 4
There are 8 routes from the firestation to streetcorner 4.

19. Design Coding Testing

20. When you actually sit
down to write some code,
you learn things that you
didn’t get from thinking
about them in modeling
terms…there is a feedback
process there that you can
only really get at from
executing some things and
seeing what works
- Martin Fowler

21. Design Testing Coding

22. Testing Coding Design

23. Test Driven Development: By Example

28. •Write a failing test = Red
•Make the test pass = Green
•Refactor = Refactor

29. Red
Green
Refactor

30. Make the Test Pass?

31. Uncle Bob’s Three Laws of TDD
• You are not allowed to write any production code unless it is to make
a failing unit test pass.
• You are not allowed to write any more of a unit test than is sufficient
to fail; and compilation failures are failures.
• You are not allowed to write any more production code than is
sufficient to pass the one failing unit test.

32. Rule of
Perpetual
Inconsequence

34. FizzBuzz
•If multiple of 3, get “Fizz”
•If multiple of 5, get “Buzz”
•If not, return input int as string
•Rules are in order

35. Fizz Buzz!
Code!

36. Clean Code that Works

37. XP Simple Design
•Passes all tests
•Clear, expressive, consistent
•No duplication
•Minimal

39. Mike Clement
• @mdclement
• mike@softwareontheside.com
• http://blog.softwareontheside.com
• https://github.com/mdclement
• http://agilecodegames.com
• Greater Sum
• @thegreatersum
• http://www.greatersum.com
• Software Craftsmanship Atlanta
• Find us on meetup.com