TDD And Refactoring
Upcoming SlideShare
Loading in...5
×
 

TDD And Refactoring

on

  • 10,219 views

Ganesan Rajamani's presentation on Test Driven Development and Refactoring. Was presented at the Agile Goa 2008 conference.

Ganesan Rajamani's presentation on Test Driven Development and Refactoring. Was presented at the Agile Goa 2008 conference.

Statistics

Views

Total Views
10,219
Views on SlideShare
10,166
Embed Views
53

Actions

Likes
17
Downloads
367
Comments
0

9 Embeds 53

http://www.slideshare.net 24
https://confluence.inside.nokiasiemensnetworks.com 11
http://static.slideshare.net 5
http://dcblr-confluence.nsn-intra.net:8090 4
http://it-esc.blogspot.com 4
http://www.linkedin.com 2
http://it-esc.blogspot.jp 1
https://confluence.inside.nsn.com 1
http://it-esc.blogspot.ru 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • In this presentation, we will try to cover three things: Explain what is TDD and its potential benefits (i.e. TDD in theory) Discuss real-life obstacles we most likely encounter while adopting TDD (i.e. TDD in practice) Role of AS APD (A)TDD champions

TDD And Refactoring TDD And Refactoring Presentation Transcript

  • 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
  • Introduction Confidential
  • 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
  • Testing Terminology
  • TDD: The Micro-Cycle of Agile Development Process
  • TDD: The Micro-Cycle of Agile Development Process
  • TDD Basics Confidential
  • 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();
    • }
    • }
  • Refactoring Confidential
  • 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