# Cindy Sridharan - Testing Microservices, the Sane Way (Highlights)  ## Highlights - asking to boot a cloud on a dev machine is equivalent to becoming multi-substrate, supporting more than one cloud provider, but one of them is the worst you’ve ever seen (a single laptop) - I’ve [previously written](https://medium.com/@copyconstruct/monitoring-in-the-time-of-cloud-native-c87c7a5bfa3e) in great detail about “post-production testing” from primarily an Observability standpoint. - [Charity Majors](https://twitter.com/mipsytipsy) gave [a talk at Strangeloop](https://www.youtube.com/watch?v=1wjovFSCGhE) this year, where she spoke about how the difference between Observability and “monitoring” really boils down to the known-unknowns and the unknown-unknowns. - The book [**Lessons Learned in Software Testing**](https://www.amazon.com/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124) has a piece of really good advice in the chapter *Thinking like a Tester*, which states: **To test, you must explore.** - The writing and running of tests is not a goal in and of itself — EVER - In the past, I’ve gone on to state that: integration tests only yield full value when the feedback is *fast*. Good (and *fast*) integration testing (both local and remote) as well as good instrumentation often serve better than striving to achieve 100% unit test coverage. - Yet another drawback of integration tests for complex systems is that it then demands maintaining separate environments for development, test, and/or staging. - The Step Up Rule - test at one layer above what’s generally advocated for. - Unit tests look more like integration tests - Integration testing looks more like testing in production - If you’re an Erlangista, you’re probably familiar with Fred Hébert’s [manual](http://erlang-in-anger.com/) on using the Erlang VM’s primitives to debug production systems while they are running. - Monitoring is a form of post-production testing - If the tests require 100% health to operate, you know you’ve got a problem.