test driven refactoring by andreas thies. xp 2004 - test driven refactoring2 overview refactoring...

Test Driven Refactoring

by Andreas Thies

XP 2004 - Test Driven Refactoring

2

Overview Refactoring Bad Smells Unit Tests

Unit Tests and Refactoring Special Smells & Refactorings Review

Testing Unit Tests


3



Testing Unit Tests


4

What‘s 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


5

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


6

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 people‘s code


7

When should‘nt I refactor When starting from the beginning

would be easier than refactoring When evaluation is close to a

deadline


8

Risks (1)

„Never touch a running system“


9

Risks (2) Editing code without adding new

functionality increases the risk of infiltrating new bugs

Refactoring code may remove functionality other developers rely on

....


10

Risk (3) So what can I to minimize the

Risk? Make small steps ! Write extensive test-suites !! Use them after each step !!!


11

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


12

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


13



Testing Unit Tests


14

What are „Bad Smells“ anything in your code, where a

refactoring seems to be overdue

perhaps detectable using certain metrics (?)


15

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


16

Bad smells (2) Switch Statements Lazy Class Speculative Generality Alternative Class with Different

Interfaces Data Class Refused Bequest Long comments


17



Testing Unit Tests


18



Testing Unit Tests


19

Validating correctness Because a refactoring don‘t

change the observable behaviour, all unit tests will run afterwards

But only, when the refactoring don‘t manipulate the interface

Most refactorings do so!


20

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


21

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


22



Testing Unit Tests


23

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


24

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


25

Mystery Guest: Solution

Inline Resource:Set up a fixture in the test code that holds the same contents as the resource


26

Smell 2: Recource Optimism Test code make optimistic

assumptions about the existence of external resources

May introduce non-deterministic behavior


27

Recource Optimism: Solution

Setup external resources:Make sure the test that uses external resources creates or allocates them before testing.


28

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


29

Test Run War: Solution

Make Resources Unique:Use unique identifiers for all resources that are allocated, for example by including a time-stamp


30

Smell 4: General Fixture The setUp()-method becomes too

general

Hard to understand Tests may slow down


31

General Fixture: Solution

Use Extract Method


32

Smell 5: Eager Test One test method checks several

methods of the object to be tested

Makes test more dependent on each other


33

Eger Test: Solution

Use Extract Method


34

Smell 6: Lazy Test Several test methods check one

method of the object to be tested

Only all tests execued together have meaning


35

Lazy Test: Solution

Use Inline Method


36

Smell 7: Assertion Roulette Test methods without explanation


37

Assertion Roulette: Solution

Add Comments !


38

Smell 8: Indirect Testing A test class no longer tests only its

counterpart in the production code


39

Indirect Testing: Solution

Problem might be caused in the production code: not enough data hiding!

Otherwise: Extract Method / Move Method


40

Smell 9: For Testers Only A production class contains

methods that are only used by test methods


41

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


42

Smell 10: Sensitive Equality Comparing by simply using

the .toString() method depends on many irrelevant details such as spaces and tabs


43

Sensitive Equality: Solution

Introduce Equality MethodDon‘t use the .toString() method but introduce a method testing the values itselve.


44



Testing Unit Tests


45

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


46



Testing Unit Tests


47

Final Question: Can you also test unit tests?


48

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


49

Code Coverage (2) CC4J - Code Coverage für Java

Applikationen 30 days limited version available http://www.scoop-gmbh.de/scoop/

downloads.htm


50

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


51

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 &&


52

Jester – A JUnit Tester (3) Advantages:

more powerfull than simple code coverage

Disadvantages: very slow – recompiling after each

change made needed


53

Now: demonstration Jester

test driven refactoring by andreas thies. xp 2004 - test driven refactoring2 overview refactoring...

Documents

test driven refactoring14

test driven refactoring6

test driven refactoring7

test driven refactoring5

field slide

method object

session slide

test driven refactoring10