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.

1. Design for Testability
Will Iverson

2. Who Is This Guy?
 Will Iverson
 wiverson@nukio.com
 Check www.nukio.com 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. Audience Qs
 Java, .NET, Other…?
 Agile, Waterfall, Other…?
 Who is your customer?

4. Basic Premise
 Design should include:
 Correctness
 Performance
 Usability
 Testability

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Real World Examples: Decoupling By Force
 OS & Application Processes
 Database Connection Recovery
 Virtual Machines (Java, .NET,VMWare, etc)
 “Chernobyl-Based Design”

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. 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. Things To Mock
 Clock
 3rd Party Services
 What about database interaction?

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. Shameless Plug
 Agile Testing
 CI, TDD
 Expert JUnit
 DBUnit, HTMLUnit, Selenium
 Automate documentation generation
 March 25th – 26th
www.nukio.com

21. Bonus Finale: Sikuli

22. Q&A