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

Test Driven Refactoring

by Andreas Thies

XP 2004 - Test Driven Refactoring

Overview Refactoring Bad Smells Unit Tests

Unit Tests and Refactoring Special Smells & Refactorings Review

Testing Unit Tests

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

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

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

When should‘nt I refactor When starting from the beginning

would be easier than refactoring When evaluation is close to a

deadline

Risks (1)

„Never touch a running system“

Risks (2) Editing code without adding new

functionality increases the risk of infiltrating new bugs

Refactoring code may remove functionality other developers rely on

Risk (3) So what can I to minimize the

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

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

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

Testing Unit Tests

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

refactoring seems to be overdue

perhaps detectable using certain metrics (?)

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

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

Interfaces Data Class Refused Bequest Long comments

Testing Unit Tests

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!

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

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

Testing Unit Tests

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

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

Mystery Guest: Solution

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

Smell 2: Recource Optimism Test code make optimistic

assumptions about the existence of external resources

May introduce non-deterministic behavior

Recource Optimism: Solution

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

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

Test Run War: Solution

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

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

general

Hard to understand Tests may slow down

General Fixture: Solution

Use Extract Method

Smell 5: Eager Test One test method checks several

methods of the object to be tested

Makes test more dependent on each other

Eger Test: Solution

Use Extract Method

Smell 6: Lazy Test Several test methods check one

method of the object to be tested

Only all tests execued together have meaning

Lazy Test: Solution

Use Inline Method

Smell 7: Assertion Roulette Test methods without explanation

Assertion Roulette: Solution

Add Comments !

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

counterpart in the production code

Indirect Testing: Solution

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

Otherwise: Extract Method / Move Method

Smell 9: For Testers Only A production class contains

methods that are only used by test methods

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

Smell 10: Sensitive Equality Comparing by simply using

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

Sensitive Equality: Solution

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

Testing Unit Tests

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

Testing Unit Tests

Final Question: Can you also test unit tests?

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

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

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

downloads.htm

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

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

Jester – A JUnit Tester (3) Advantages:

more powerfull than simple code coverage

Disadvantages: very slow – recompiling after each

change made needed

Now: demonstration Jester

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

test driven refactoring14

test driven refactoring6

test driven refactoring7

test driven refactoring5

field slide

method object

session slide

test driven refactoring10

Documents

kayak: safe semantic refactoring to java streams · driven...

refactoring and integration testing or strategy, introduced...

model-driven java code refactoring...model-driven java code...

refactoring legacy code driven by tests - eng

a model-driven approach to refactoring

model-driven software refactoring - mathematik und...

reflections on teaching refactoring: a tale of two...

wrapup of refactoring example...refactoring should not cause...

consistent model selection and data-driven smooth tests...

automated translation among epsilon languages for...

module 1. introducing course: refactoring. overview...

model-driven software refactoring - … · refactoring is a...

refactoring unit-tests - clean code days · 2016. 7. 6. ·...

applying unit tests & test-driven development€¦ ·...

refactoring, re nement, and...

test-driven development + refactoring

quality-driven refactoring - uni bremen filerebecca tiarks...

refactoring to patterns - indicthreads...• refactoring and...

refactoring junit tests - nordic testing days ·...

refactoring classes lesson six: classes. refactoring classes...