The Primacy of Testability

This presentation is on how to use testability as a proxy for other quality attributes, and how to leverage it as a tool for managing architectures.

This version of the slides was presented at XP Days Ukraine 2014.

1. @sixty_north The Primacy of Testability A barometer for the busy architect 1 Austin Bingham @austin_bingham
4. Testability as a barometer for software architects
5. Multiple projects ! ! What makes the job difficult?
6. Multiple projects Large, fast projects ! What makes the job difficult?
7. Multiple projects Large, fast projects Complex interactions What makes the job difficult?
8. Multiple projects Large, fast projects Complex interactions Mental overload What makes the job difficult?
9. Testability Performance Extensibility Scalability Security Maintainability Modularity Usability Modifiability tells us about Quality
10. Ground Rules Some definitions to set the stage Qualities Correlated with Testability Review of a few software qualities and their relationship to testability Application How these principles apply to the real world 1 2 3
11. Help Wanted! Software Architect ! !
12. Help Wanted! Software Architect ! Job responsibilities include:
13. Help Wanted! Software Architect ! Job responsibilities include: •Drawing Boxes and/or Arrows
14. Help Wanted! Software Architect ! Job responsibilities include: •Drawing Boxes and/or Arrows •Managing Non-Functional Requirements !
15. Help Wanted! Software Architect ! Job responsibilities include: •Drawing Boxes and/or Arrows •Managing Non-Functional Requirements ! MUST KNOW HOW TO CODE!
16. What is testability?
17. What is testability? Easy Hard
18. What is testability? Easy Hard Observability Heterogeneity Understandability etc.
20. Why testability?
21. Why testability? Testability is special!
22. testability tested
23. Ground Rules Some definitions to set the stage Qualities Correlated with Testability Review of a few software qualities and their relationship to testability Application How these principles apply to the real world 1 2 3
24. Ground Rules Some definitions to set the stage Qualities Correlated with Testability Review of a few software qualities and their relationship to testability Application How these principles apply to the real world 1 2 3 Modularity Performance Scaling up development SOLID Modifiability
25. Breaking down software Reasoning in isolation Minimal dependencies Design, develop, repair, replace Modularity
26. Modularity + Testability Independent instantiation Testing in isolation Fewer distant dependencies Confident testing Easier to understand Thorough testing
29. Listen to your tests
30. Ground Rules Some definitions to set the stage Qualities Correlated with Testability Review of a few software qualities and their relationship to testability Application How these principles apply to the real world 1 2 3 Modularity Performance Scaling up development SOLID Modifiability
31. ! ! Performance ! ! ! Everything else
32. ! ! Performance ! ! ! Everything else ! Testability is key to hitting performance goals
33. Where you’re going.
35. Wasted effort on incorrect focus Early, unnecessary compromise
36. Monitor and manage compromises
37. Monitor and manage compromises Make best performance changes
38. Qualities Correlated with Testability Review of a few software qualities and their relationship to testability Application How these principles apply to the real world 2 3 Modularity Performance Scaling up development SOLID Modifiability Ground Rules Some definitions to set the stage 1
39. Bridging technical and business
43. Testing Dept.
44. Testing Dept.
45. Testing Dept. Documentation Team
46. • Independent development ! • Development with confidence ! • Easier integration with infrastructure
47. Qualities Correlated with Testability Review of a few software qualities and their relationship to testability Application How these principles apply to the real world 2 3 Modularity Performance Scaling up development SOLID Modifiability Ground Rules Some definitions to set the stage 1
48. SOLID Principles Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion
49. Single responsibility Do one thing and do it well
50. Single responsibility ComponentObject ComponentObject(. . .); void render(); bool serialize(); uint activate(); COList children(); bool isAlive(); void dealloc(); void kill(); void ensureActiveIfVisible();
51. Single responsibility ComponentObject ComponentObject(. . .); void render(); bool serialize(); uint activate(); COList children(); bool isAlive(); void dealloc(); void kill(); void ensureActiveIfVisible(); CompoundCO MainView StorageMgr
52. Single responsibility ComponentObject ComponentObject(. . .); void render(); bool serialize(); uint activate(); COList children(); bool isAlive(); void dealloc(); void kill(); void ensureActiveIfVisible(); How many tests? Expected behavior? Interactions?
53. Single responsibility ComponentObject ComponentObject(. . .); void render(); bool serialize(); uint activate(); COList children(); bool isAlive(); void dealloc(); void kill(); void ensureActiveIfVisible(); Displayable Serializable Activatable
54. SOLID Principles Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion
55. Open-closed Open for extension Closed for modification
56. Open-closed double getSpeed() { switch (_type) { case EUROPEAN: return getBaseSpeed(); case AFRICAN: return getBaseSpeed() - getLoadFactor() * _numberOfCoconuts; case NORWEGIAN_BLUE: return (_isExParrot) ? 0 : getBaseSpeed(_voltage); } throw new RuntimeException ("Should not be unreachable"); } Bird European African NorwegianBlue getSpeed(): double «abstract» getSpeed(): double getSpeed(): double getSpeed(): double M = E - N + 2P M = 4 - 5 + 2×4 M = 7 M = 1 M = 1 M = 1 ΣM = 3
57. 57 “How many if statements does it take to add a feature?” Rob Galanakis, Technical Director, Eve Online
58. SOLID Principles Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion
59. Liskov substitution Replacing base with derived preserves behavior
60. Liskov substitution BaseClass SubclassA
61. Liskov substitution BaseClass SubclassA Test PASS
62. Liskov substitution BaseClass SubclassA Test SubclassB FAIL
63. Liskov substitution BaseClass SubclassA Test SubclassB
64. SOLID Principles Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion
65. Interface segregation Prefer cohesive, focused interfaces
66. Interface segregation IKitchenSink MyClass
67. Interface segregation IKitchenSink MyClass MockSink This is a lot of work!
68. SOLID Principles Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion
69. Dependency inversion Depend upon abstractions; low depends on high
70. Dependency inversion void relayMessage(string msg) {! SatelliteUplink sup;! sup.initialize();! sup.send(msg);! }!
71. Dependency inversion void relayMessage(string msg) {! SatelliteUplink sup;! sup.initialize();! sup.send(msg);! }! void relayMessage(string msg, Relay& r) {! r.send(msg);! }! ! class SatelliteUplink : public Relay { . . . };! ! class MockRelay : public Relay { . . . };!
72. SOLID Principles Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion SOLID code is testable code. Testable code is probably SOLID!
73. Qualities Correlated with Testability Review of a few software qualities and their relationship to testability Application How these principles apply to the real world 2 3 Modularity Performance Scaling up development SOLID Modifiability Ground Rules Some definitions to set the stage 1
74. I am incredibly modifiable!
75. Modifiability follows other qualities Modularity Reduced Coupling Low “ripple”
76. Modularity Reduced Coupling Low “ripple” Modifiability follows other qualities SOLID Easier to understand Simpler modification
77. Strong tests allow you to make changes safely Make riskier changes, and make faster changes
78. Make the best changes
79. Qualities Correlated with Testability Review of a few software qualities and their relationship to testability Application How these principles apply to the real world 2 3 Modularity Performance Scaling up development SOLID Modifiability Ground Rules Some definitions to set the stage 1
80. Qualities Correlated with Testability Review of a few software qualities and their relationship to testability Application How these principles apply to the real world 2 3 Ground Rules Some definitions to set the stage 1
81. Qualities Correlated with Testability Review of a few software qualities and their relationship to testability Application How these principles apply to the real world 2 3 Agile methods Test-Driven Design Domain-Driven Design Ground Rules Some definitions to set the stage 1
82. individual developer Planning Sprint Review 1 2 3 stand-up Agile and feedback
83. Agile and feedback Testability can be a strong signal in agile feedback loops individual developer Planning Sprint Review 1 2 3 stand-up
84. Where you’re going. Where you start.
85. How long your code needs to stay agile. Where you’re going. Where you start.
86. Qualities Correlated with Testability Review of a few software qualities and their relationship to testability Application How these principles apply to the real world 2 3 Agile methods Test-Driven Design Domain-Driven Design 4 Ground Rules Some definitions to set the stage 1
87. Write a failing test Make the test pass Refactor Test-Driven Design
88. Write a failing test Make the test pass Refactor Test-Driven Design
89. Write a failing test Make the test pass Refactor Test-Driven Design
90. Implicit Benefits are “built in” Testability is always a focus
91. Implicit Benefits are “built in” Testability is always a focus Explicit Refactoring loop Well positioned! TDD’s strength is based on some of the same ideas
92. Qualities Correlated with Testability Review of a few software qualities and their relationship to testability Application How these principles apply to the real world 2 3 Agile methods Test-Driven Design Domain-Driven Design 4 Ground Rules Some definitions to set the stage 1
93. Domain-Driven Design
94. Domain-Driven Design Center development activities around a core model of the domain
95. Domain-Driven Design Center development activities around a core model of the domain
96. A DDD domain model is highly testable
97. A DDD domain model is highly testable Strong reasons to consider using DDD!
98. Outro argumentum ad auctoritatem
99. “One reasonable definition of good design is testability. It is hard to imagine a software system that is both testable and poorly designed. It is also hard to imagine a software system that is well designed but also untestable.” Uncle Bob Martin
100. “Design for testability...is of paramount importance when successfully constructing large and very large C++ systems.” John Lakos
101. “There appears to be a synergy between testability (at the unit level) and good design. If you aim for testability and make some good choices, design gets better. If you aim for good design, your design becomes more testable.” Michael Feathers Photo by Fraser Speirs
102. Questions? Austin Bingham @austin_bingham @sixty_north
103. Questions? Austin Bingham @austin_bingham @sixty_north