Guerilla Testing C++
or, "How to discover the Gold Nuggets in your Big Ball of Mud"
Change is the most expensive part of the cost of a software project. The biggest impediments to change are lack of clarity on what to alter to effect the change, and uncertainty about unintended side-effects of the change.
No matter how badly a C++ codebase is enmeshed, you can get it under test if you know how to master its coupling. This example-driven course shows you how.
Many long-lived codebases have evolved to a point where some, perhaps most, aspects of its functionality are no longer precisely known / codified / automatically tested. This course will teach you, using practical examples, how to wrest control from any codebase, no matter how badly enmeshed, isolate known pieces of good functionality, get them under test, and eventually to isolate and separate them into a new context, while, where required, maintaining compatibility with their original context.
This course will teach you how to refactor any codebase with confidence, rather than poking at the edges of its functionality in fear.
LevelIntermediate. Discussion uses C and C++ code examples - because they afford examination of the most challenging problems - and so assumes prior experience of C and/or C++, but several of the concepts and techniques are applicable to other languages.
StylePresentation, including demonstrations of code evolution (including compiling, running, testing). Attendees may follow along on their own computers if they wish.
Duration2 days: lectures + question & answer sessions
- The slippery slope - it's easy to do
How to tell if you've got a Big Ball of Mud?
- Release costs
- Red lava
- Bet your life?
Factors that inhibit testing
- Coupling, coupling, coupling
- The inconstant environment
- Defensive code
- Fuzzy (or no!) abstraction borders
- Where there's hope ...
Identifying Key Characteristics in situ
- Code Coverage
Things to remember when Testing Mud-balls
- Unit testing vs Component testing
- Coverage (in realistic time)
Only change what you can test (and are testing!)
- Exceptions to this rule
- Beyond salvation: sometimes it's just mud
Creating islands of Known Functionality
- Identifying Units
- Identifying Components
- Identifying Modules
- Striding two worlds
- When to "throw it out"
Handling the Inconstant Environment
- File system
- Data storage
Practical Techniques for Mastering Coupling
- Dynamic library redirection
- Class Adaptor
- Instance Adaptor
- Versioned testing
Preferably, case studies are selected from and prepared on a per-client basis. Alternatively, several stock case studies - based on Synesis' own projects - may be used.
Each case study will apply the concepts and techniques discussed in the presentation to a badly-enmeshed component/library in a step-wise manner, with the end result of a component.