Download to read offline
More Related Content
Similar to Design for Testability in Practice
Design for Testability in Practice
- 1. 1 Design forTestability Who am I? Nir Szilágyi Finance, Risk & Compliance, Internet, Telecom, CRM, Video Streaming. Engineering, QE, QA, Release Eng nszilagyi@paypal.com | norberts@gmail.com
- 2. 2 Goals vsSystems 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. 3 What dothe Experts Say? What is Testability? – James Bach James Bach’s dimensions of Testability -‐ link
- 4. 4 What isTestability? – 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. 5 Design" " Code" " Test What isgood 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. 6 Service ArchitectureExample 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. 7 • Separationof 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. 8 • Separationof 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. 9 Application LayersExample 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. 10 Distributed Multi-FlowApplication Layers Service Interface s Message Types Business Workflow Business Component s Data Access Components Data UXliXes DB UI Compon ents PresentaXo n Logic Presentation Service Business Data Cache Messaging Service Interface s Message Types Business Workflow Business Component s Data Access Components Data UXliXes DB UI Compon ents PresentaXo n Logic Cache Messaging Service Interface s Message Types Business Workflow Business Component s Data Access Components Data UXliXes DB UI Compon ents PresentaXo n 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. 11 A Noteon 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. 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. 13 Design Patternsfor 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. 14 The BasicTesting 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. 15 Design forTestability… Testable software -> Goal Good design, clean code, effective testing -> Systems
- 16. 16 …Thank You… nszilagyi@paypal.com | norberts@gmail.com