1
Design for Testability
Who am I?
Nir Szilágyi Finance, Risk & Compliance, Internet, Telecom, CRM, Video Streaming. Engineering, QE, QA, Release Eng
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]