Refactoring for Testability (or how I learned to stop worrying and love failing tests) Presented by...

Refactoring for Testability

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

Presented by Aaron Evans <aarone@one-shore.com>

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

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

Push down

Consolidate

Expose

Substitute

Pull up

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 <aarone@one-shore.com>

Refactoring for Testability (or how I learned to stop worrying and love failing tests) Presented by...

Documents

Testability Guidelines

Software testability slide share

Testability Measure

ATPG - 3 Testability Design

Testability Primer (Rev. D

Beyond Basic Unit Testing: Mocks, Stubs, User Interfaces, and Refactoring for Testability

Carnap. Testability and Meaning

Design for Testability 1 - ASICasic.co.in/ppt/DFTnew.pdf · Design for Testability 2 Testability • Controllability: The ability to set some circuit nodes to a certain states or

Refactoring For Testability

Increasing Code Testability through Automated Refactoringmeloc/MScASE/resources/... · Increasing Code Testability through Automated Refactoring Final Year Project Final Report Dermot

Better Refactoring Tools for a Better Refactoring …web.cecs.pdx.edu/~black/publications/BetterTools.pdfBetter Refactoring Tools for a Better Refactoring Strategy Emerson Murphy-Hill

Detangling a Code Base: Measuring Testability of ... · seeing how much code coverage, C(C), can be achieved on the class in a set amount of testing time, refactoring to improve T(C),

Refactoring & Testability. Testing in OOP programming No life in flexible methodologies and for refactoring- infected developers without SOME kind of

Testability of Integrated Circuits

Design For Testability Design For Testability

Testability Measures

Testability: Factors and Strategy

Testability for Developers

Refactoring to Patterns - IndicThreads...• Refactoring and Agile Techniques • Refactoring and Functional Requirements • Refactoring and TDD • Simple Design and Code Smells

SMTA Testability Guidelines TP-101C PROMO · SMTA Testability Guidelines Third Edition Page 4 of 71 INTRODUCTION An Overview of the SMTA Testability Guidelines These Testability Guidelines