TDD And Refactoring

TDD and Refactoring Ganesan R Sr.Software Developer Sabre Holdings

Game Plan Introduction (A Little Bit of Theory) TDD Basics Guidelines for Testable Design Refactoring and its Techniques

What is TDD? A Simple Definition Write a Failing (Automated) Test Before Writing Production Code Make a Minimal Change to Production Code to Fix the Failing Test When There are Enough Tests, Re-factor the code Primary Goals: Simplicity, Readability & No Duplication Reliance Upon Automated Test Safety Net Both Production & Test Code Two Primary Goals of Writing Tests Safety Net Documentation

TDD: The Micro-Cycle of Agile Development Process

TDD Basics (Discussion & Demo) Good Test is Atomic & Isolated Decomposing Requirements Into a Test List Programming by Intention Making the Compiler Happy Running the Failing Test Making the Test Pass Repeating it Again for Other Tests In the List Breadth-First vs. Depth-First Let’s Not Forget to Re-factor Both Production & Test Code Re-factoring Remove Duplication Re-factoring toward smaller methods Keeping things in balance

TDD Concepts & Patterns What to Test & in What Order? Details vs. big picture Uncertain vs. familiar High value vs. low-hanging fruit Happy path vs. error situations Implementation Strategies Faking it Triangulation Obvious Implementation Prime Guidelines for Test-Driving Do Not Skip Re-factoring Get to Green Fast Slow Down After a Mistake

TDD Concepts & Patterns (Continued) Unit-Testing Concepts Using Test Fixtures Using Test Doubles (More Details to Follow)

Test Doubles (Alternative Implementations) An Example of a Test Double Reasons for Having Test Doubles Avoiding a Landslide of Failing Tests Avoiding Slow Running Tests Avoiding Availability (Existence) Problems Avoiding Difficult Instantiation And/Or Configuration Test Double Taxonomy Stubs Fakes Mocks Exercise

Point Of Sale System… As an example, we’ve chosen a point-of-sale system, like one might encounter in any retail store. A sales clerk passes items over a scanner that reads the barcode. A display monitor shows information on each item as it is scanned and also tracks the total for each sale of one or more items to a given shopper. Sample User Story The total price of all items in the sale is available.

Guidelines for Testable Design Confidential

Guidelines for Testable Design Choose composition over inheritance Avoid static and the Singleton Isolate dependencies Inject dependencies

Choose Composition Over inheritance Inheriting lets subclass to inherit all the functionality of Superclass. Downside – Introduce inconvenient constraints related to Instantiating the subclass in test harness. Composition allows more flexible design solution for reusability. Example – Allows to instantiate the composite object with alternative implementations

Dependency Injection Refers to supplying an external dependency to a software component. Forms of Dependency Injection – interface injection , in which the exported module provides an interface that its users must implement in order to get the dependencies at runtime setter injection , in which the dependent module exposes a setter method which the framework uses to inject the dependency . constructor injection , in which the dependencies are provided through the class constructor.

Constructor Injection.. public class ImportantClass { IFoo foo; public ImportantClass() { this.foo = new EnterpriseFoo(); } void doReallyImportantStuff() { this.foo.bar(); } } public class ImportantClass { IFoo foo; public ImportantClass(IFoo foo) { this.foo = foo; } void doReallyImportantStuff() { this.foo.bar(); } }

What is Refactoring? Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations.

What is Refactoring? Each transformation (called a 'Refactoring') does little, but a sequence of transformations can produce a significant restructuring. The system is also kept fully working after each small Refactoring, reducing the chances that a system can get seriously broken during the restructuring.

Why Do we refactor ? Improves the design of the software. Easier to maintain and understand. Easier to facilitate change. More flexibility. Increased reusability. To help find bugs

When do we refactor ? Duplicated code. Long method. Long parameter list.. Improper naming.

Refactoring Techniques Here are some of the Refactoring techniques discussed in the session Sprout Method Sprout Class Wrap Method Wrap Class

Sprout Method While adding new feature to the existing method it can formulated completely as a new method. How ? Write the code in the new method. Call it from the places where the new functionality needs to be Example: Public class TransactionGate { Public void postEntries(List entries){ for(Iterator it=entries.iterator();it.hasNext();){ Entry entry=(Entry)it.next(); entry.postDate(); } } transactionBundle.getListManager.add(entries) ; } }

Sprout method - Continue Public class TransactionGate { Public void postEntries(List entries){ List entriesToAdd=uniqueEntries(entries); -------- } } transactionBundle.getListManager.add(entries) ; } List uniqueEntries(List entries) { //Unique Entries impl comes here } }

Sprout method - steps Identify the place to make the code change If the change can be formulated as a single sequence of statement write down a call for the new method that will do the work involved and comment it out. Determine the local variables you need from the source method and make them arguments for the call.

Sprout method - steps Determine whether the sprouted method will need to return values to source method. If so change the call so that its return value is assigned to a variable. Develop the sprout method using TDD. Remove the comment in the source code to enable the call.

Sprout Class Sprout method is powerful but in some tangled dependency situation it is not powerful though Example: std::string QuaterlyReportGenerator::generate() { std::veactor<Result> results=database.queryResults(beginDate,endDate) ; std::string pageText ; pageText+=“<html><head><title>Quaterly Report</title></head> <body><table>” if(results.size()!=0){ //html page generator code comes here } }

Sprout class - Continues Suppose if we need to add a new functionality. Add a Header row for the HTML table its producing. “ QuaterlyReportGenerator” is a huge class to get into test harness. Formulate the new change into a little class and bring it in test harness. class QuaterlyReportTableHeaderGenerator{ public: string generate() ; }

Sprout class - continues Move the generate method to a interface. Class HTMLGenerator{ public : virtual ~HTMLGenerator() ; virtual string generate() ; } Make QuaterlyReportGenerator and QuaterlyReportTableHeaderGenerator inherit from HTMLGenerator. Now the new class is in testharness at somepoint in time we would be able to get the QuaterlyReportGenerator also in test harness.

Sprout class - steps Identify where you need to make the code change. Think of a good name for the class, create an object of the class and call the method that will do the work ; then comment the lines. Determine the local variables you need from the source method and make them as constructor arguments.

Sprout class - steps Determine whether the sprouted class will need to return value to the source method. If so, provide a method in the class that will supply those values and add a call to the source method to receive the same. Develop the sprout class test first.

Further.. Recommended reading Working Effective with Legacy code By Michael Feathers http://www.refactoring.com/sources.html Refactoring: Improving the Design of Existing Code – Martin Fowler http://tech.groups.yahoo.com/group/refactoring/ http://www.refactoring.com/tools.html

TDD And Refactoring

In this document