Test-Driven DevelopmentKenneth M. AndersonUniversity of Colorado, BoulderCSCI 4448/6448 — Lecture 27 — 12/2/08© University of Colorado, 2008Tuesday, December 2, 20082Credit where Credit is Due• Some of the material for this lecture is taken from “Test-Driven Development” by Kent Beck• as such some of this material is copyright © Addison Wesley, 2003• In addition, some material for this lecture is taken from “Agile Software Development: Principles, Patterns, and Practices” by Robert C. Martin• as such some materials is copyright © Pearson Education, Inc., 2003Tuesday, December 2, 20083Goals for this lecture• Introduce the concept of Test-Driven Development (TDD)• Present several examplesTuesday, December 2, 20084Test-Driven Development• The idea is simple• No production code is written except to make a failing test pass• Implication• You have to write test cases before you write codeTuesday, December 2, 20085Writing Test Cases First• This means that when you first write a test case, you may be testing code that does not exist• And since that means the test case will not compile, obviously the test case “fails”• After you write the skeleton code for the objects referenced in the test case, it will now compile, but also may not pass• So, then you write the simplest code that will make the test case passTuesday, December 2, 2008Example (I)• Consider writing a program to score the game of bowling• You might start with the following testpublic class TestGame extends TestCase {public void testOneThrow() {Game g = new Game();g.addThrow(5);assertEquals(5, g.getScore());}}• When you compile this program, the test “fails” because the Game class does not yet exist. But:• You have defined two methods on the class that you want to use• You are designing this class from a client’s perspective6Tuesday, December 2, 2008Example (II)• You would now write the Game classpublic class Game {public void addThrow(int pins) {}public int getScore() {return 0;}}• The code now compiles but the test will still fail: getScore() returns 0 not 5• In Test-Driven Design, Beck recommends taking small, simple steps• So, we get the test case to compile before we get it to pass7Tuesday, December 2, 2008Example (III)• Once we confirm that the test still fails, we would then write the simplest code to make the test case pass; that would bepublic class Game {public void addThrow(int pins) {}public int getScore() {return 5;}}• The test case now passes!8Tuesday, December 2, 2008Example (IV)• But, this code is not very useful!• Lets add a new test case to enable progresspublic class TestGame extends TestCase {public void testOneThrow() {Game g = new Game();g.addThrow(5);assertEquals(5, g.getScore());}public void testTwoThrows() {Game g = new Game()g.addThrow(5)g.addThrow(4)assertEquals(9, g.getScore());}}• The first test passes, but the second case fails (since 9 ≠ 5)• This code is written using JUnit; it uses reflection to invoke tests automatically9Tuesday, December 2, 2008Example (V)• We have duplication of information between the first test and the Game class• In particular, the number 5 appears in both places• This duplication occurred because we were writing the simplest code to make the test pass• Now, in the presence of the second test case, this duplication does more harm than good• So, we must now refactor the code to remove this duplication10Tuesday, December 2, 2008Example (VI)public class Game {private int score = 0;public void addThrow(int pins) {score += pins;}public int getScore() {return score;}}11Both tests now pass. Progress!Tuesday, December 2, 2008Example (VII)• But now we to make additional progress, we add another test case to the TestGame class…public void testSimpleSpare() {Game g = new Game()g.addThrow(3); g.addThrow(7); g.addThrow(3);assertEquals(13, g.scoreForFrame(1));assertEquals(16, g.getScore());}…• We’re back to the code not compiling due to scoreForFrame()• We’ll need to add a method body for this method and give it the simplest implementation that will make all three of our tests cases pass12Tuesday, December 2, 200813TDD Life Cycle• The life cycle of test-driven development is• Quickly add a test• Run all tests and see the new one fail• Make a simple change• Run all tests and see them all pass• Refactor to remove duplication• This cycle is followed until you have met your goal;• note that this cycle simply adds testing to the “add functionality; refactor” loop covered in the last two lecturesTuesday, December 2, 200814TDD Life Cycle, continued• Kent Beck likes to perform TDD using a testing framework, such as JUnit.• Within such frameworks• failing tests are indicated with a “red bar”• passing tests are shown with a “green bar”• As such, the TDD life cycle is sometimes described as• “red bar/green bar/refactor”Tuesday, December 2, 2008JUnit: Red Bar...• When a test fails:• You see a red bar• Failures/Errors are listed• Clicking on a failure displays more detailed information about what went wrong15Tuesday, December 2, 200816Example Background:Multi-Currency Money • Lets design a system that will allow us to perform financial transactions with money that may be in different currencies• e.g. if we know that the exchange rate from Swiss Francs to U.S. Dollars is 2 to 1 then we can calculate expressions like• 5 USD + 10 CHF = 10 USD• or• 5 USD + 10 CHF = 20 CHFTuesday, December 2, 200817Starting From Scratch• Lets start developing such an example• How do we start?• TDD recommends writing a list of things we want to test• This list can take any format, just keep it simple• Example• $5 + 10 CHF = $10 if rate is 2:1• $5 * 2 = $10Tuesday, December 2, 200818First Test• The first test case looks a bit complex, lets start with the second• 5 USD * 2 = 10 USD• First, we write a test casepublic void testMultiplication() {Dollar five = new Dollar(5);five.times(2);assertEquals(10, five.amount)}Tuesday, December 2, 200819Discussion on Test Casepublic void testMultiplication() {Dollar five = new Dollar(5);five.times(2);assertEquals(10, five.amount)}• What benefits does this provide?• target class plus some of its interface• we are designing the interface of the Dollar class by thinking about how we would want to use it• We have made a testable assertion about the state of that class after we perform a
View Full Document
Unlocking...