How to do in-app chaos testing
summary
Demo of the open‑source library retro shows how to inject failures inside .NET apps without external agents: extensions for Microsoft DI decorate services to UWP/ASP.NET Core apps, causing Windows Hello sign‑in to throw after N calls, adding 30s latency to a customer API, making the logger throw an IO exception when disk is full, or returning corrupted customer objects. Code acts as a controllable man‑in‑the‑middle so you can find and fix real failure modes early.
AI-written summary · about
chapters (16)
- 0:00Introduction and speaker background
- 1:25What is chaos engineering
- 3:14Chaos engineering at Netflix and Amazon
- 7:29Chaos engineering vs testing
- 8:55Scaling chaos engineering down
- 11:03Why chaos engineering is needed
- 15:04Testing offline and poor connections
- 17:33Introducing Retro library
- 19:47Demo setup and first chaos test
- 23:46Simulating Windows Hello failure
- 27:20Fixing the Windows Hello bug
- 31:48Slowing down CRM API calls
- 36:20Simulating disk space exhaustion
- 42:08Returning altered customer data
- 51:34Summary and Retro features
- 54:23Q&A session
related talks
58mHow to do in-app chaos testing
45mApplication reliability with Azure Load Testing and Chaos Studio Q&A
34mResilient Cloud App: Chaos Engineering, Azure Studio
01h 02m1,2,3… testing: is this thing on(line)? Meet your new Microsoft Testing tools
40mResilience Testing - Failure is an Option
46mDesigning a System for Chaos
01h 11mChaos Engineering: Unleash the Monkeys
24mHow to solve intermittent issues, aka Random Failures
