Design For Testability


Published on

If you had an opportunity to build an application from the ground up, with testability a key design goal, what would you do?

In this presentation, we will look at just such a situation - a major, two year rewrite of a suite of core business systems. We will discuss how a system looks when testability is as important as functionality - and what it looks like when quality concerns are part of the initial design. We will look at the role of test automation and manual test in a modern project, and look at the tools and processes. The session will conclude with a demo of the latest visual test automation tool from MIT and a Q&A.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Design For Testability

  1. 1. Design for Testability Will Iverson
  2. 2. Who Is This Guy?   Will Iverson    Check for LinkedIn, Twitter, etc.   Java since 1995   Pascal/C/C++ before that…   Apple, Symantec, Sun, BEA…   Four books on Java   Hibernate, Web Services, Mac OS X Java, Jakarta Commons   Today: Architect, Consultant, Manager, Coach   All Star Directories, Architect   Nukio, Coach/Trainer/Consultant
  3. 3. Audience Qs   Java, .NET, Other…?   Agile, Waterfall, Other…?   Who is your customer?
  4. 4. Basic Premise   Design should include:   Correctness   Performance   Usability   Testability
  5. 5. Why Design Testability?   Care about quality of work   Want rapid feedback   Want to solve problem correctly   Want to be able to make changes without fear   Want to be a team working toward same goals!
  6. 6. What is Design?   Design : planning that lays the basis for making of every object or system   Both a noun & verb   Things you design…   Database models   System components   User interfaces   Process for adding features & fixing issues
  7. 7. Typical Web App Development Flow Current Software • Validate (customer, market, product management, etc.) Deploy New Feature or Fix • Validate non-functional • What does it do? (perf, system) Test Design • Verify against requirements • Database changes • Negative tests • Code Implement • Database changes • Code
  8. 8. Design for Testability Current Software •  Validate (customer, market, product management, etc.) Deploy New Feature or Fix •  Validate non-functional (perf, •  What does it do? system) Implement Design How you test & •  Tests •  Tests what you test •  Database changes •  Database changes informs the •  Code •  Code design!
  9. 9. Agile, Waterfall, Other…?   Agile   Test Driven Development, Behavior Driven Development, Acceptance Test Driven Development   Reality check: team dynamic?   Waterfall   Typical: QA handed requirements, software: figure it out   Lucky: QA test plan is included in initial sign off   Freeform   Sit in the same room, hash it out daily
  10. 10. Sample: Code Centric High Level Stack Presentation •  External Web Site (Spring MVC) •  Internal Tools (Grails) •  Partner API (XML via HTTPS) •  Reporting (Jasper) Business Logic •  Spring •  Hibernate Database •  Data Model •  Data Set[s]
  11. 11. Example: Testable High Level Stack Design Presentation Spring Controller Tests •  External Web Site (Spring MVC) Canoo Web Tests •  Internal Tools (Grails) Selenium •  Partner API (XML via HTTPS) HTMLUnit •  Reporting (Jasper) Report Monitoring Job[s] Business Logic JUnit •  Spring DbUnit •  Hibernate Mockito (external services) Database p6spy •  Data Model Jailer •  Data Set[s] LiquiBase How would I test and identify the resolution to any open issues?
  12. 12. Sample: Typical Model Design   “There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.”   C.A.R. Hoare
  13. 13. Testable Model Design Revenue Test this independently of Recognition Service everything else • 6 public interface methods Lead Delivery Service • 4 public interface methods Lead Generation Service • 3 public interface methods
  14. 14. Complexity Kills Services   Stateless interfaces   Avoid complex choreography   Single request/response actions   More than 5-8 tables? More than 5-8 classes?   Break it up   But… it’s not complicated enough!?   Exactly.   What about Integration Tests?   Are you testing integration, or are you testing coupled components   Coupled components = revisit design!
  15. 15. Real World Examples: Decoupling By Force   OS & Application Processes   Database Connection Recovery   Virtual Machines (Java, .NET,VMWare, etc)   “Chernobyl-Based Design”
  16. 16. Test at the Right Place   Don’t test your database through the GUI   Don’t test your business logic through the GUI   You can’t test APIs (remote/distributed or traditional) via GUI
  17. 17. Common Challenges   JavaScript   You can test JavaScript via Selenium if properly implemented   Takes work & discipline   Bad HTML   Test: can you push back on dev to get proper ids?   Layout & Design Fidelity   Browsershots   Many hosted services
  18. 18. Things To Mock   Clock   3rd Party Services   What about database interaction?
  19. 19. Things To Do   Someone needs to do exploratory testing   QA background is key   Someone needs to automate the testing   Avoid manual regression – oh, the humanity!   Someone needs to validate with the customer   Acceptance tests?
  20. 20. Shameless Plug   Agile Testing   CI, TDD   Expert JUnit   DBUnit, HTMLUnit, Selenium   Automate documentation generation   March 25th – 26th
  21. 21. Bonus Finale: Sikuli
  22. 22. Q&A