Put the Tests Before the Code

Post on 10-Apr-2017

194 views 0 download

Transcript of Put the Tests Before the Code

Put the Tests before the Code: Coding the

Right WayMike Clement@mdclement

mike@softwareontheside.comhttp://blog.softwareontheside.com

http://agilecodegames.com

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 nameFor Part 1 only, you may assume all strings passed to the arena's adding method will be of the correct formatFor Part 1 only, you may assume all strings passed to the arena's getting and removing methods will be names already existing in the arenaPart 2 - Let the Battle Begin (8 points)

Extend the FighterInterface provided; details about abilities, stats, and more can be found in the FighterInterfaceFor 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 completeCompletion of Part 1 is required to submit Part 2Part 3 - Fortify the Walls (5 points)

Make adding new fighters to your arena bullet-proofThis involves rejecting any string that is not of the correct format or that would add a duplicate name to the arenaMake getting and removing existing fighters in your arena bullet-proofCompletion of Part 1 is required to submit Part 3Part 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 typeThe 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 typeCompletion of Part 1 is required to submit Part 4

Clean Code that Works

Plan

Requirements

Design

Coding

Testing

Release

Design

Coding

Testing

Plan

Requirements

Design

Coding

Testing

Release

Design

Coding

Testing

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

Sample Input

61 21 33 43 54 65 62 32 40 0

4 2 33 45 11 67 88 92 55 73 11 84 66 90 0

Sample Output

CASE 1:1 2 3 4 61 2 3 5 61 2 4 3 5 61 2 4 61 3 2 4 61 3 4 61 3 5 6There are 7 routes from the firestation to streetcorner 6.

CASE 2:1 3 2 5 7 8 9 6 41 3 41 5 2 3 41 5 7 8 9 6 41 6 41 6 9 8 7 5 2 3 41 8 7 5 2 3 41 8 9 6 4There are 8 routes from the firestation to streetcorner 4.

Unit tests

Fail

Pass

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

Sample Input

61 21 33 43 54 65 62 32 40 0

4 2 33 45 11 67 88 92 55 73 11 84 66 90 0

Sample Output

CASE 1:1 2 3 4 61 2 3 5 61 2 4 3 5 61 2 4 61 3 2 4 61 3 4 61 3 5 6There are 7 routes from the firestation to streetcorner 6.

CASE 2:1 3 2 5 7 8 9 6 41 3 41 5 2 3 41 5 7 8 9 6 41 6 41 6 9 8 7 5 2 3 41 8 7 5 2 3 41 8 9 6 4There are 8 routes from the firestation to streetcorner 4.

Design Coding Testing

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

Design Testing Coding

Testing Coding Design

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

RedGreen

Refactor

Make the Test Pass?

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.

Rule of Perpetual

Inconsequence

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

Fizz Buzz!Code!

Clean Code that Works

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

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