Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Put the Tests Before the Code

584 views

Published on

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.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Put the Tests Before the Code

  1. 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. 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. 3. Clean Code that Works
  4. 4. Plan Requirements Design Coding Testing Release
  5. 5. Design Coding Testing
  6. 6. Plan Requirements Design Coding Testing Release
  7. 7. Design Coding Testing
  8. 8. 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
  9. 9. 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.
  10. 10. Unit tests
  11. 11. Fail Pass
  12. 12. Is there more? How do you know when you’re done?
  13. 13. 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.
  14. 14. Design Coding Testing
  15. 15. 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
  16. 16. Design Testing Coding
  17. 17. Testing Coding Design
  18. 18. Test Driven Development: By Example
  19. 19. •Write a failing test = Red •Make the test pass = Green •Refactor = Refactor
  20. 20. Red Green Refactor
  21. 21. Make the Test Pass?
  22. 22. 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.
  23. 23. Rule of Perpetual Inconsequence
  24. 24. FizzBuzz •If multiple of 3, get “Fizz” •If multiple of 5, get “Buzz” •If not, return input int as string •Rules are in order
  25. 25. Fizz Buzz! Code!
  26. 26. Clean Code that Works
  27. 27. XP Simple Design •Passes all tests •Clear, expressive, consistent •No duplication •Minimal
  28. 28. 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

×