Chapter 21 TestDriven Development CS 6359 Fall 2011

  • Slides: 13
Download presentation
Chapter 21 Test-Driven Development CS 6359 Fall 2011 John Cole 1

Chapter 21 Test-Driven Development CS 6359 Fall 2011 John Cole 1

Write the Tests First • Tests are written before the code • Developer writes

Write the Tests First • Tests are written before the code • Developer writes unit tests for nearly all production code CS 6359 Fall 2011 John Cole 2

Advantages • The tests actually get written • Programmer satisfaction leads to more consistent

Advantages • The tests actually get written • Programmer satisfaction leads to more consistent test writing • Clarification of detailed interface and behavior • Provable, repeatable, automated verification • Confidence to change things CS 6359 Fall 2011 John Cole 3

Example • To test the Sale class, create a Sale. Test class that: –

Example • To test the Sale class, create a Sale. Test class that: – Creates a Sale (the thing to be tested; a fixture) – Adds some line items to it with the make. Line. Item method – Asks for the total and verifies that it is the expected value CS 6359 Fall 2011 John Cole 4

Pattern of Testing Methods • • Create the fixture Do some operation you want

Pattern of Testing Methods • • Create the fixture Do some operation you want to test Evaluate the results Point: Don’t write all of the tests for Sale first; write one test method, implement the solution in Sale to make it pass, then repeat CS 6359 Fall 2011 John Cole 5

Using x. Unit • Create a class that extends the Test. Case class •

Using x. Unit • Create a class that extends the Test. Case class • Create a separate testing method for each Sale method you want to test. This will generally be every public method. CS 6359 Fall 2011 John Cole 6

Refactoring • A structured, disciplined method to rewrite or restructure existing code without changing

Refactoring • A structured, disciplined method to rewrite or restructure existing code without changing its external behavior, applying small transformations and re-testing each step. • Unit tests applied after each step ensure that the changes didn’t cause a problem CS 6359 Fall 2011 John Cole 7

Goals of Refactoring • • Remove duplicate code Improve clarity Make long methods shorter

Goals of Refactoring • • Remove duplicate code Improve clarity Make long methods shorter Remove the use of hard-coded literal constants CS 6359 Fall 2011 John Cole 8

Code Smells • • Duplicated code Big methods Class with many instance variables Class

Code Smells • • Duplicated code Big methods Class with many instance variables Class with lots of code Strikingly similar subclasses Little or no use of interfaces High coupling CS 6359 Fall 2011 John Cole 9

Basic Refactorings • Extract method – Convert a long method into shorter ones by

Basic Refactorings • Extract method – Convert a long method into shorter ones by moving part of it into a helper method • Extract constant – Replace a literal with a constant variable • Introduce explaining variable – put the results of an expression into a temporary variable with a name that explains its purpose • Replace constructor call with Factory Method – CS 6359 Fall 2011 John Cole 10

More Refactorings • Change method parameters (changes them in the definition, then finds all

More Refactorings • Change method parameters (changes them in the definition, then finds all references) • Replace using new with a call to a method that returns an object. (Factory pattern) CS 6359 Fall 2011 John Cole 11

Code example Public class Die { public static final int MAX=6; public int face.

Code example Public class Die { public static final int MAX=6; public int face. Value; public Die(){ roll(); } Public void roll() { face. Value = (int)((Math. Random() * MAX) + 1; } Public int get. Face. Value() { return face. Value; } } CS 6359 Fall 2011 John Cole 12

Another Example • roll. Dice on 392 CS 6359 Fall 2011 John Cole 13

Another Example • roll. Dice on 392 CS 6359 Fall 2011 John Cole 13