Test Driven Refactoring by Andreas Thies. XP 2004 - Test Driven Refactoring2 Overview Refactoring Bad Smells Unit Tests Unit Tests and Refactoring Special.

Slides:



Advertisements
Similar presentations
12-Dec-14 Refactoring IV. Previously discussed bad smells Duplicated code — and other forms of redundancy Long method — use short methods that delegate.
Advertisements

A practical guide John E. Boal TestDrivenDeveloper.com.
Test-Driven Development and Refactoring CPSC 315 – Programming Studio.
© 2010 Shawn A. Bohner Software Construction and Evolution - CSSE 375 Even more Bad Smells in Code Shawn & Steve Q1 Shawn & Steve Hint 
You want me to do what??? Refactoring legacy applications aka : fixing someone else’s “bad” code Niel Zeeman Team Foundation Consulting
Gregor Gisler-Merz BrownBag Session Refactoring.
Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative to refactoring.
Software Construction and Evolution - CSSE 375 Bad Smells in Code Shawn Bohner & Steve Chenoweth.
1 Software Maintenance and Evolution CSSE 575: Session 1, Part 4 Even more Bad Smells in Code Steve Chenoweth Office Phone: (812) Cell: (937)
Test-Driven Development and Refactoring Project 3 Lecture 1 CPSC 315 – Programming Studio Fall 2009.
JUnit. What is unit testing? A unit is the smallest testable part of an application. A unit test automatically verifies the correctness of the unit. There.
Introduction to Refactoring Excerpted from ‘What is Refactoring?’ by William C. Wake and Refactoring: Improving the Design of Existing Code by Martin Fowler.
George Blank University Lecturer. REFACTORING Improving the Design of Existing Code Supplement to Ian Sommerville, Software Engineering, Chapter 20 Prepared.
XP and Refactoring David Talby. Development Methodologies The Software Crisis – 84% of software projects are not on time – 31% of software projects never.
REFACTORING Improving the Design of Existing Code Atakan Şimşek e
Maintenance Refactoring and Code Smells. Where are we? Over the semester we have talked about Software Engineering. The overall goal of software engineering.
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
CISC6795: Spring Object-Oriented Programming: Polymorphism.
1 v1.6 08/02/2006 Overview of Eclipse Lectures 1.Overview 2.Installing and Running 3.Building and Running Java Classes 4.Refactoring 5.Debugging 6.Testing.
What is Refactoring? CSE301 University of Sunderland Harry R. Erwin, PhD.
Refactoring Cristescu Marilena. Definitions Loose Usage: Reorganize a program(or something) As a noun: a change made to the internal structure of some.
Software Refactoring Part I: Introduction Bartosz Walter Advanced Object-Oriented Design Lecture 5.
Sadegh Aliakbary Sharif University of Technology Spring 2012.
LECTURE 38: REFACTORING CSC 395 – Software Engineering.
Refactoring. Mathematics: Factor ● fac·tor – One of two or more quantities that divides a given quantity without a remainder, e.g., 2 and 3 are factors.
Refactoring - A disciplined approach to rework for better design.
Software Engineering 1 Object-oriented Analysis and Design Chap 21 Test-Driven Development and Refactoring.
Refactoring Improving the structure of existing code Refactoring1.
17-Oct-15 Refactoring. 2 Refactoring is: restructuring (rearranging) code......in a series of small, semantics-preserving transformations (i.e. the code.
Small changes to code to improve it. Refactoring Defined A change made to the internal structure of software to make it easier to understand and cheaper.
Refactoring (continued) Source: "Refactoring: Improving the Design of Existing Code", Martin Fowler.
SWE 316: Software Design and Architecture Objectives Lecture # 20 Improving the existing design: Refactoring SWE 316: Software Design and Architecture.
When and How to Refactor? Refactoring Patterns Alexander Vakrilov Telerik Corporation Senior Developer and Team Leader.
Refactoring1 Improving the structure of existing code.
The effectiveness of refactoring based on a compatibility testing taxonomy and a dependency graph Steve Counsell and Robert Hierons, Brunel University,
Refactoring Deciding what to make a superclass or interface is difficult. Some of these refactorings are helpful. Some research items include Inheritance.
Introduction to Refactoring Jim Cooper Falafel Software.
Object Oriented Software Development
Informatics 122 Software Design II
1 CSC/ECE 517 Fall 2010 Lec. 3 Overview of Eclipse Lectures Lecture 2 “Lecture 0” Lecture 3 1.Overview 2.Installing and Running 3.Building and Running.
Software Engineering CS3003 Lecture 4 Code bad smells and refactoring.
Refactoring and such ● (Side note) Specialization ● Key terms ● Abstraction, state, persistence and association and their relationship to software development.
Refactoring: Code Smells. Admin Notes REGISTER FOR BLACKBOARD Watch blackboard site for updates on class as hurricane season approaches.
Refactoring. Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative.
E L EARNING E NVIRONMENT FOR S OFTWARE E NGINEERING E DUCATION (R EFACTORING A GENT ) A.Stoyanova-Doycheva University of Plovdiv г. 10th Workshop.
Refactoring 2. Admin Blackboard Quiz Acknowledgements Material in this presentation was drawn from Martin Fowler, Refactoring: Improving the Design of.
REFACTORINGREFACTORING. Realities Code evolves substantially during development Requirements changes 1%-4% per month on a project Current methodologies.
NJIT 1 Test Driven Development and Refactoring Larman, Chapter 21.
Module 3. Smells Between Classes Course: Refactoring.
1 Software Maintenance and Evolution CSSE 575: Session 2, Part 1 Refactoring Principles Steve Chenoweth Office Phone: (812) Cell: (937)
Software Construction and Evolution - CSSE 375 Making Method Calls Simpler Shawn and Steve Below – “Be the character!” The late acting teacher Lee Strasberg.
Refactoring. Mathematics: Factor ● fac·tor – One of two or more quantities that divides a given quantity without a remainder, e.g., 2 and 3 are factors.
Refactoring1 Improving the structure of existing code.
Pertemuan 12 Refactoring Mata kuliah: T0144 – Advanced Topics in Software Engineering Tahun: 2010.
Refactoring. 2 Process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal.
CSSE 375 Organizing Data – Part 1 Shawn and Steve Q1.
Refactoring. DCS – SWC 2 Refactoring ”A change made to the internal structure of software to make it easier to understand and cheaper to modify without.
Module 9. Dealing with Generalization Course: Refactoring.
Catalog of Refactoring (6) Making Method Calls Simpler.
Principles and examples
Module Road Map Refactoring Why Refactoring? Examples
Overview of Eclipse Lectures
Code Smells 1.
Improving the structure of existing code
Refactoring and Code Smells
Refactoring.
Refactoring and Code Smells
Refactoring.
Refactoring and Code Smells
Presentation transcript:

Test Driven Refactoring by Andreas Thies

XP Test Driven Refactoring2 Overview Refactoring Bad Smells Unit Tests Unit Tests and Refactoring Special Smells & Refactorings Review Testing Unit Tests

XP Test Driven Refactoring3 Overview Refactoring Bad Smells Unit Tests Unit Tests and Refactoring Special Smells & Refactorings Review Testing Unit Tests

XP Test Driven Refactoring4 Whats Refactoring? A change made to the internal structure of software to make it easier to understand to make it cheaper to modify without changing its observable behaviour

XP Test Driven Refactoring5 Why should I refactor? Refactoring improves the design of software Refactoring makes software easyer to understand Refactoring helps to find and prevent bugs Refactoring helps you program faster

XP Test Driven Refactoring6 When should I refacor Refactor when you need to fix a bug Refactor as you do a code review Refactor when you try to understand other peoples code

XP Test Driven Refactoring7 When shouldnt I refactor When starting from the beginning would be easier than refactoring When evaluation is close to a deadline

XP Test Driven Refactoring8 Risks (1) Never touch a running system

XP Test Driven Refactoring9 Risks (2) Editing code without adding new functionality increases the risk of infiltrating new bugs Refactoring code may remove functionality other developers rely on....

XP Test Driven Refactoring10 Risk (3) So what can I to minimize the Risk? Make small steps ! Write extensive test-suites !! Use them after each step !!!

XP Test Driven Refactoring11 Catalog of refactorings (1) Add Parameter Change Bidirectional Association to Unidirectional Change Reference to Value Change Unidirectional Association to Bidirectional Change Value to Reference Collapse Hierarchy Consolidate Conditional Expression Consolidate Duplicate Conditional Fragments Convert Dynamic to Static Construction Convert Static to Dynamic Construction Decompose Conditional Duplicate Observed Data Eliminate Inter-Entity Bean Communication Encapsulate Collection Encapsulate Downcast Encapsulate Field Extract Class Extract Interface Extract Method Extract Package Extract Subclass Extract Superclass Form Template Method Hide Delegate Hide Method Hide presentation tier- specific details from the business tier Inline Class Inline Method Inline Temp Introduce A Controller Introduce Assertion Introduce Business Delegate Introduce Explaining Variable Introduce Foreign Method Introduce Local Extension Introduce Null Object Introduce Parameter Object Introduce Synchronizer Token Localize Disparate Logic Merge Session Beans Move Business Logic to Session Move Class Davison Move Field Move Method Parameterize Method Preserve Whole Object Pull Up Constructor Body Pull Up Field Pull Up Method Push Down Field

XP Test Driven Refactoring12 Catalog of refactorings (2) Push Down Method Reduce Scope of Variable Refactor Architecture Remove Assignments to Parameters Remove Control Flag Remove Double Negative Remove Middle Man Remove Parameter Remove Setting Method Rename Method Replace Array with Object Replace Assignment with Initialization Replace Conditional with Polymorphism Replace Conditional with Visitor Replace Constructor with Factory Method Replace Data Value with Object Replace Delegation with Inheritance Replace Error Code with Exception Replace Exception with Test Replace Inheritance with Delegation Replace Iteration with Recursion Replace Magic Number with Symbolic Constant Replace Method with Method Object Replace Nested Conditional with Guard Clauses Replace Parameter with Explicit Methods Replace Parameter with Method Replace Record with Data Class Replace Recursion with Iteration Replace Static Variable with Parameter Replace Subclass with Fields Replace Temp with Query Replace Type Code with Class Replace Type Code with State/Strategy Replace Type Code with Subclasses Reverse Conditional Self Encapsulate Field Separate Data Access Code Separate Query from Modifier Split Loop Split Temporary Variable Substitute Algorithm Use a Connection Pool Wrap entities with session

XP Test Driven Refactoring13 Overview Refactoring Bad Smells Unit Tests Unit Tests and Refactoring Special Smells & Refactorings Review Testing Unit Tests

XP Test Driven Refactoring14 What are Bad Smells anything in your code, where a refactoring seems to be overdue perhaps detectable using certain metrics (?)

XP Test Driven Refactoring15 Bad smells (1) Duplicated Code Long Method Large Class Long Parameter List Divergent Change Shotgun Surgery

XP Test Driven Refactoring16 Bad smells (2) Switch Statements Lazy Class Speculative Generality Alternative Class with Different Interfaces Data Class Refused Bequest Long comments

XP Test Driven Refactoring17 Overview Refactoring Bad Smells Unit Tests Unit Tests and Refactoring Special Smells & Refactorings Review Testing Unit Tests

XP Test Driven Refactoring18 Overview Refactoring Bad Smells Unit Tests Unit Tests and Refactoring Special Smells & Refactorings Review Testing Unit Tests

XP Test Driven Refactoring19 Validating correctness Because a refactoring dont change the observable behaviour, all unit tests will run afterwards But only, when the refactoring dont manipulate the interface Most refactorings do so!

XP Test Driven Refactoring20 Types of refactoring (1) Compatible e.g. split temporary variable no need to update tests Backwards compatible e.g. pull up field add aditional tests

XP Test Driven Refactoring21 Types of refactoring (2) Refactorings that can be made backwards compatible e.g. rename method mark the old interface as deprecated add aditional tests Incompatible refactorings e.g. hide method

XP Test Driven Refactoring22 Overview Refactoring Bad Smells Unit Tests Unit Tests and Refactoring Special Smells & Refactorings Review Testing Unit Tests

XP Test Driven Refactoring23 Bad smells in Unit Test Same as the production code, unit tests are java code also Most of bad smells will fit here too Aditional to this there are few more smells with their own refactorings

XP Test Driven Refactoring24 Smell 1: Mystery Guest A test using external recources like a testfile is no longer self contained Introduces hidden depencies This makes it hard to use the test as an aditional documentation

XP Test Driven Refactoring25 Mystery Guest: Solution Inline Resource: Set up a fixture in the test code that holds the same contents as the resource

XP Test Driven Refactoring26 Smell 2: Recource Optimism Test code make optimistic assumptions about the existence of external resources May introduce non-deterministic behavior

XP Test Driven Refactoring27 Recource Optimism: Solution Setup external resources: Make sure the test that uses external resources creates or allocates them before testing.

XP Test Driven Refactoring28 Smell 3: Test Run War A test uses special recources making it unable to be run by more than one programmer a time Introduces non-deterministic behaviour

XP Test Driven Refactoring29 Test Run War: Solution Make Resources Unique: Use unique identifiers for all resources that are allocated, for example by including a time-stamp

XP Test Driven Refactoring30 Smell 4: General Fixture The setUp()-method becomes too general Hard to understand Tests may slow down

XP Test Driven Refactoring31 General Fixture: Solution Use Extract Method

XP Test Driven Refactoring32 Smell 5: Eager Test One test method checks several methods of the object to be tested Makes test more dependent on each other

XP Test Driven Refactoring33 Eger Test: Solution Use Extract Method

XP Test Driven Refactoring34 Smell 6: Lazy Test Several test methods check one method of the object to be tested Only all tests execued together have meaning

XP Test Driven Refactoring35 Lazy Test: Solution Use Inline Method

XP Test Driven Refactoring36 Smell 7: Assertion Roulette Test methods without explanation

XP Test Driven Refactoring37 Assertion Roulette: Solution Add Comments !

XP Test Driven Refactoring38 Smell 8: Indirect Testing A test class no longer tests only its counterpart in the production code

XP Test Driven Refactoring39 Indirect Testing: Solution Problem might be caused in the production code: not enough data hiding! Otherwise: Extract Method / Move Method

XP Test Driven Refactoring40 Smell 9: For Testers Only A production class contains methods that are only used by test methods

XP Test Driven Refactoring41 For Testers Only: Solution Problem caused in the production code! Remove these methods or if they are needed to set up the tests use Extract Method / Move Method

XP Test Driven Refactoring42 Smell 10: Sensitive Equality Comparing by simply using the.toString() method depends on many irrelevant details such as spaces and tabs

XP Test Driven Refactoring43 Sensitive Equality: Solution Introduce Equality Method Dont use the.toString() method but introduce a method testing the values itselve.

XP Test Driven Refactoring44 Overview Refactoring Bad Smells Unit Tests Unit Tests and Refactoring Special Smells & Refactorings Review Testing Unit Tests

XP Test Driven Refactoring45 Bad Smells in Tests – Review Most of bad smells and refactorings will fit for unit tests also There are several special bad smells and refactorings for unit tests Bad smells in unit tests can indicate problems in the production code

XP Test Driven Refactoring46 Overview Refactoring Bad Smells Unit Tests Unit Tests and Refactoring Special Smells & Refactorings Review Testing Unit Tests

XP Test Driven Refactoring47 Final Question: Can you also test unit tests?

XP Test Driven Refactoring48 Code Coverage (1) Report during test which parts of the production code are not executed With this information you can easily find out which parts of the production code are still untested

XP Test Driven Refactoring49 Code Coverage (2) CC4J - Code Coverage für Java Applikationen 30 days limited version available gmbh.de/scoop/downloads.htm

XP Test Driven Refactoring50 Jester – A JUnit Tester (1) Free available tester for JUnit tests Modifies the production code and reexecutes the tests suites now they should fail, otherwise there are untested functions in production code

XP Test Driven Refactoring51 Jester – A JUnit Tester (2) Changes made by Jester: modifying literal numbers changing true to false / false to true changing if( to if(true || changing if( to if(false &&

XP Test Driven Refactoring52 Jester – A JUnit Tester (3) Advantages: more powerfull than simple code coverage Disadvantages: very slow – recompiling after each change made needed

XP Test Driven Refactoring53 Now: demonstration Jester