Design for Testability in Practice

1  

Design for Testability

Who am I?

Nir Szilágyi  Finance, Risk & Compliance, Internet, Telecom, CRM, Video Streaming. Engineering, QE, QA, Release Eng

[email protected] | [email protected]  

2  

Goals vs Systems

What is Testability?

• How easy is to test software • The hidden cost of software • Higher Testability –

•  Better tests (easier env setup, data prep) •  Higher tester efficiency •  Faster tests •  Better debugability (is that a word?) •  Better test efficiency and effectiveness

• Pain (problem) and B/WCS (solution).

3  

What do the Experts Say?

What is Testability? – James Bach

James  Bach’s  dimensions  of  Testability  -­‐  link  

4  

What is Testability? – Kelly & Kedemo

Ben  Kelly  and  Maria  Kedemo’s  dimensions  of  Testability  -­‐link  

Why does it matter?

• Testing takes too long. • What do we have to do to fail the code? • How long till we find the issue? • Who can fix the code and how fast? • How soon ready for re-test? • An aspect of Technical Debt (SQALE)

• The hidden cost of software

5  

Design��

Code� �

Test

What is good design?  The  real  criteria  for  quality  of  design,  “minimizes  cost  (including  the  cost  of  delay)  and  maximizes  benefit  over  the  life>me  of  the  so?ware,”    -­‐  Kent  Beck

Design

6  

Service Architecture Example

Gateway  

Service  B   Service  A  

Data  Models  and  Rules  

500  Data  Elements  

SLA:  2  seconds   SLA:    200ms  

Yes,  No,  Maybe  

70%  30%  

Simple  Data  Model  and  few  rules  

Users  

Application Layers Example

Service  Interfaces   Message  Types  

Business  Workflow   Business  Components  

Data  Access  Components   Data  UXliXes  DB  

UI  Components   PresentaXon  Logic  

Presentation layer

Service Layer

Business Layer

Data Layer

Cache  

Users   Clients  

Messaging  

7  

•  Separation of Concerns •  Single Responsibility Principle •  Principle of Least Knowledge • Do not Repeat the Functionality • Unified Exception Handling Mechanism •  Points of Control and Observation (AOP) • Naming conventions - for test code too • Define Data format for a layer and between • Define clear contract between layers • How are you going to test this?

Design

8  

•  Separation of Concerns •  Single Responsibility Principle •  Principle of Least Knowledge • Do not Repeat the Functionality • Unified Exception Handling Mechanism •  Points of Control and Observation (AOP) • Naming conventions - for test code too • Define Data format for a layer and between • Define clear contract between layers • How are you going to test this?

Design

•  Inner layer dependencies • Cross layer dependencies • Code dependencies • Rule/Code separation

Design - Dependencies

9  

Application Layers Example

Service  Interfaces   Message  Types  

Business  Workflow   Business  Components  

Data  Access  Components   Data  UXliXes  DB  

UI  Components   PresentaXon  Logic  

Presentation layer

Service Layer

Business Layer

Data Layer

Cache  

Users   Clients  Messaging  

Testability traps

• Non  determinisXc  dependencies  • Race  condiXons  • Message  latency  •  Threading  • CRUD  operaXons  on  shared  data  • Complexity  

•  Accidental    •  EssenXal  

10  

Distributed Multi-Flow Application Layers

Service  Interface

s  

Message  Types  

Business  Workflow  

Business  Component

s  

Data  Access  Components  

Data  UXliXes   DB  

UI  Components  

PresentaXon  Logic  

Presentation

Service

Business

Data

Cache  Messaging  

Service  Interface

s  

Message  Types  

Business  Workflow  

Business  Component

s  

Data  Access  Components  

Data  UXliXes   DB  

UI  Components  

PresentaXon  Logic  

Cache  Messaging  

Service  Interface

s  

Message  Types  

Business  Workflow  

Business  Component

s  

Data  Access  Components  

Data  UXliXes   DB  

UI  Components  

PresentaXon  Logic  

Cache  Messaging  

User  

Login  Add  to  Cart  

Pay  

Code

• Code  Testability  measurement  -­‐  >  How  painful  is  it  to  write  a  good  unit  test  • ComposiXon  over  inheritance  • No  cyclic  dependencies  • Dependency  injecXon  • Beck’s  five  rules:  

•  Passes  all  the  tests  •  Reveals  intenXon  •  No  duplicaXon  •  Fewest  elements  

11  

A Note on Clean Code

“Clean code is like a well written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control” – Grady Booch “Clean code does one thing well” – Bjorn Straustroup “Clean code can be read and enhanced by a developer other than its original author. It provides one way of doing one thing” – “Big Dave Thomas” “Clean code always looks like it was written by someone who cares. There is nothing obvious you can do to make it better” – Michael Feathers

A Note on Craftmanship

A  crabsman  takes  pride  in  his  work  an  strives  to  do  the  best  job  he  can.    WriXng  clean  code  is  what  you  must  do  in  order  to  call  yourself  a  professional.  There  is  no  reasonable  excuse  to  do  anything  less  than  your  best.  

 Sense  of  ownership.  You  fork  it,  you  write  it,  you  own  it.    

12  

Testing

• Design  paderns  for  testability.  •  Treat  test  code  almost  like  producXon  code.  •  External  vs.  internal  factors  

• Controllability  • Observability  

•  Service  interface  validator  (AOP)  

Service Architecture Example

Gateway  

Service  B   Service  A  

Data  Models  and  Rules  

500  Data  Elements  

SLA:  2  seconds   SLA:    200ms  

Yes,  No,  Maybe  

70%  30%  

Simple  Data  Model  and  few  rules  

Users  

13  

Design Patterns for Test Code

•  Factory  (ex.  abstract  request  types)  • Builder  (ex.  construct  Service  Request)  •  Singleton  (ex.  DB  connecXon)  •  Façade  (ex.  abstract  test  logic)  • Command  (ex.  controlling  UI  elements)  •  Template  (ex.  Test  objects)  

• Learn learn learn •  Upfront •  As you go

• Look at the code • Be there

•  Relationships • Confidence • Hands on vs. technical leadership

A Note on the Role of the Test Manager

14  

The Basic Testing Needs

Observability: •  The ability to see the

product we are testing •  The ability to determinate

test status and reports •  The ability to observe

behavior and output

Controllability: •  The ability to invoke

any possible state or combination of states of the product

•  The ability to manipulate interim behavior or outputs

More Test side impact

•  Tester Knowledge •  Team composition •  Relationships •  Eng, PO, Architects

•  Environment •  Data, Data, Data •  Dev Process, CI, CD. •  Test Plan - Review

15  

Design for Testability…

Testable software -> Goal

Good design, clean code, effective testing -> Systems

16  

…Thank  You…  [email protected] | [email protected]