Testability and Managing Software Architectures

This presentation looks at how testability can be used to help us monitor and manage software architectures.

1. @sixty_north Testability and Managing Software Architectures A barometer for the busy architect 1 Austin Bingham @austin_bingham 1
4. Testability as a barometer for software architects 4
5. Multiple projects Large, fast projects Complex interactions Mental overload What makes the job difficult? 5
6. Multiple projects Large, fast projects Complex interactions Mental overload What makes the job difficult? 6
7. Multiple projects Large, fast projects Complex interactions Mental overload What makes the job difficult? 7
8. Multiple projects Large, fast projects Complex interactions Mental overload What makes the job difficult? 8
9. Testability Performance Extensibility Scalability Security Maintainability Modularity Usability Modifiability 9
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 10
11. Help Wanted! Software Architect Job responsibilities include: •Drawing Boxes and/or Arrows •Managing Non-Functional Requirements MUST KNOW HOW TO CODE! 11
12. Help Wanted! Software Architect Job responsibilities include: MUST KNOW HOW TO CODE! 12
13. Help Wanted! Software Architect Job responsibilities include: •Drawing Boxes and/or Arrows MUST KNOW HOW TO CODE! 13
14. Help Wanted! Software Architect Job responsibilities include: •Drawing Boxes and/or Arrows •Managing Non-Functional Requirements MUST KNOW HOW TO CODE! 14
15. Help Wanted! Software Architect Job responsibilities include: •Drawing Boxes and/or Arrows •Managing Non-Functional Requirements MUST KNOW HOW TO CODE! 15
16. What is testability? 16
17. What is testability? Easy Hard 17
18. What is testability? Easy Hard Observability Heterogeneity Understandability etc. 18
20. Why testability? 20
21. Why testability? Testability is special! 21
22. testability tested 22
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 23
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 24
25. Modularity 25
26. Breaking down software Modularity 25
27. Breaking down software Reasoning in isolation Modularity 25
28. Breaking down software Reasoning in isolation Minimal dependencies Modularity 25
29. Breaking down software Reasoning in isolation Minimal dependencies Design, develop, repair, replace Modularity 25
30. Modularity + Testability 26
31. Modularity + Testability Independent instantiation Testing in isolation 26
32. Modularity + Testability Independent instantiation Testing in isolation Fewer hidden dependencies Confident testing 26
33. Modularity + Testability Independent instantiation Testing in isolation Fewer hidden dependencies Confident testing Easier to understand Thorough testing 26
36. Listen to your tests 29
37. 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 30
38. Performance Everything else 31
39. Performance Everything else Testability is key to hitting performance goals 32
40. Where you’re going. 33
42. Wasted effort on incorrect focus 35
43. Wasted effort on incorrect focus Early, unnecessary compromise 35
44. Monitor and manage compromises 36
45. Monitor and manage compromises Make best performance changes 37
46. 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 38
47. Bridging technical and business 39
51. Testing Dept. 43
52. Testing Dept. 44
53. Testing Dept. Documentation Team 45
54. • Independent development • Development with confidence • Easier integration with infrastructure 46
55. 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 47
56. SOLID Principles Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion 48
57. Single responsibility Do one thing and do it well 49
58. Single responsibility ComponentObject ComponentObject(. . .); void render(); bool serialize(); uint activate(); COList children(); bool isAlive(); void dealloc(); void kill(); void ensureActiveIfVisible(); 50
59. Single responsibility ComponentObject ComponentObject(. . .); void render(); bool serialize(); uint activate(); COList children(); bool isAlive(); void dealloc(); void kill(); void ensureActiveIfVisible(); CompoundCO MainView StorageMgr 51
60. 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? 52
61. Single responsibility ComponentObject ComponentObject(. . .); void render(); bool serialize(); uint activate(); COList children(); bool isAlive(); void dealloc(); void kill(); void ensureActiveIfVisible(); Displayable Serializable Activatable 53
62. SOLID Principles Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion 54
63. Open-closed Open for extension Closed for modification 55
64. 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 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 56
65. 57 “How many if statements does it take to add a feature?” Rob Galanakis, Technical Director, Eve Online 57
66. SOLID Principles Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion 58
67. Liskov substitution Replacing base with derived preserves behavior 59
68. Liskov substitution BaseClass SubclassA 60
69. Liskov substitution BaseClass SubclassA Test PASS 61
70. Liskov substitution BaseClass SubclassA Test SubclassB FAIL 62
71. Liskov substitution BaseClass SubclassA Test SubclassB 63
72. SOLID Principles Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion 64
73. Interface segregation Prefer cohesive, focused interfaces 65
74. Interface segregation IKitchenSink MyClass 66
75. Interface segregation IKitchenSink MyClass MockSink 67
76. Interface segregation IKitchenSink MyClass MockSink This is a lot of work! 67
77. SOLID Principles Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion 68
78. Dependency inversion Depend upon abstractions; low depends on high 69
79. Dependency inversion void relayMessage(string msg) { SatelliteUplink sup; sup.initialize(); sup.send(msg); } 70
80. 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 { . . . }; 71
81. SOLID Principles Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion 72
82. SOLID Principles Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion SOLID code is testable code. 72
83. SOLID Principles Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion SOLID code is testable code. Testable code is probably SOLID! 72
84. 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 73
86. I am incredibly modifiable! 74
87. Modifiability follows other qualities Modularity Reduced Coupling Low “ripple” 75
88. Modularity Reduced Coupling Low “ripple” Modifiability follows other qualities SOLID Easier to understand Simpler modification 76
89. Strong tests allow you to make changes safely Make riskier changes, and make faster changes 77
90. Make the best changes 78
91. 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 79
92. 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 80
93. 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 Be involved in the code Agile methods Test-Driven Design Domain-Driven Design Greenfield vs. Brownfield 81
94. Understand how changes impact testability 82
96. 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 Be involved in the code Agile methods Test-Driven Design Domain-Driven Design Greenfield vs. Brownfield 84
97. individual developer Planning Sprint Review 1 2 3 stand-up Agile and feedback 85
98. individual developer Planning Sprint Review 1 2 3 stand-up Agile and feedback Testability can be a strong signal in agile feedback loops 86
99. Where you’re going. Where you start. 87
100. How long you need to stay agile. Where you’re going. Where you start. 88
101. 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 Be involved in the code Agile methods Test-Driven Design Domain-Driven Design Greenfield vs. Brownfield 89
102. Write a failing test Make the test pass Refactor Test-Driven Design 90
103. Write a failing test Make the test pass Refactor Test-Driven Design 91
104. Write a failing test Make the test pass Refactor Test-Driven Design 92
105. Implicit Benefits are “built in” Testability is always a focus 93
106. Implicit Benefits are “built in” Testability is always a focus Explicit Refactoring loop Well positioned! 94
107. 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 94
108. 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 Be involved in the code Agile methods Test-Driven Design Domain-Driven Design Greenfield vs. Brownfield 95
109. Domain-Driven Design 96
110. Domain-Driven Design Center development activities around a core model of the domain 97
111. Domain-Driven Design Center development activities around a core model of the domain 98
112. A DDD domain model is highly testable 99
113. A DDD domain model is highly testable Modular? 99
114. A DDD domain model is highly testable Modular? Performant? 99
115. A DDD domain model is highly testable Modular? Performant? Scales up? 99
116. A DDD domain model is highly testable Modular? Performant? Scales up? Modifiable? 99
117. A DDD domain model is highly testable Modular? Performant? Scales up? Modifiable? SOLID? 99
118. A DDD domain model is highly testable Modular? Performant? Scales up? Modifiable? SOLID? Strong reasons to consider using DDD! 100
119. 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 Be involved in the code Agile methods Test-Driven Design Domain-Driven Design Greenfield vs. Brownfield 101
122. Tests may already exist 103
123. Tests may already exist Testability may still be low 103
124. Tests may already exist Testability may still be low Maybe no or few tests! 103
125. Tests may already exist Testability may still be low Maybe no or few tests! 104
126. Outro argumentum ad auctoritatem 105
127. “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 106
128. “Design for testability...is of paramount importance when successfully constructing large and very large C++ systems.” John Lakos 107
129. “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 108
130. Questions? Austin Bingham @austin_bingham @sixty_north 109
131. Questions? Austin Bingham @austin_bingham @sixty_north 110