Refactoring For Testability

Refactoring for Testability

(or how I learned to stop worrying and love failing tests)

Presented by Aaron Evans <[email protected]>


What is refactoring?

What is testability?

How do we do it?


Why refactor?

My code is good


Why refactor?

The only constant is change


User Interface Code

Separate business logic from display logic

Encapsulate implementation details

Don’t tie your code to vendor

Don’t hard code configurationHandle errors

gracefully

Use meaningful variable names

Don’t expose other layers


Refactoring the UI

Yes, Virginia, there really is display logic

ID tags

Individually testable components

Maintainable UI tests


Push testing down the stack

Reduce brittle UI tests

Run tests faster

Isolate the system under test

Think about code as individual components


SOLID

Single Responsibility PrincipleOpen / Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

Liskov Substitution Principle


Refactoring Strategies

http://www.refactoring.com/catalog/

Extract

Change

Encapsulate

Hide

Push down

Move

Consolidate

Expose

Substitute

Pull up

http://www.refactoring.com/catalog/


This…Becomes…

Implementation


Adding Layers of Abstraction

Composition over Inheritance

Indirection

Reusability

Database Abstraction LayerORM

Domain ModelBusiness Logic


Simplifying Interfaces

Exposing Functionality


Decoupling

Presentation and Business Logic

Persistence and Domain Objects

Interface from Implementation


Dependency Injection

No news is good news

No framework is necessary

Factory pattern

Constructors / Setters / Builders

Loose Coupling


Extract Interface

Inject Dependency


Use Mocks

Single Responsibility


Reduce Dependencies


Coding in business terms

Common domain language

Acceptance criteria

BDD frameworks – RSPEC, Specflow, JBehave

Thanks...

Questions?

Aaron Evans <[email protected]>

Refactoring For Testability

Documents

Transcript of Refactoring For Testability