* Dev env doesn't usually have long-term or complete sets of cached data.
* Cache should be agnostic to model changes.
* Do object structure comparison when pulling from cache.
+ * Testing how your app deals with 'old' data, not the infrastructure.
+5. Writing tests can improve coding habits
+ * Smaller, modular code is testable, 200-line functions aren't.
+ * Discover easily-testable coding patterns.
+ * Functions should perform a *single function*.
+7. How do I enforce testing on my team?
+ * Most people don't like 2AM fires.
+ * Iterate faster with confidence.
+ * Git pre-commit hooks, stop checkins without tests.
+ * Coverage.py can make it a game.
+8. How much testing is enough testing?
+ * No simple answer for that.
+9. Junction between Unit and Integration
+ * Difficult areas to test, because behavior is dependant upon environment.
+10. Testing a virgin codebase: 0-100%
+ * You will refactor code as you write tests
+11. Successful strategies
+ * Require unit tests for all code going forward
+ * Reserve time to clear out test debt
+ * Good for new team members
+ * Everyone takes a turn
+ * Establish a good foundation to build on
+ * Every bug is two bugs:
+ * One in the code that broke
+ * One is the test that would/will catch the bug
+ * Fixtures, mocks, ObjectCreator
+13. Should I get test data from cache?
+ * No. Adds unnecessary complexity to unit tests.
+ * If tests only succeed with certain caches, probably some code that can be refactored.
+14. Graceful code degredation
+ * Devs need to think outside their dev instance
+ * Service unavailable shouldn't mean your site is unavailable
+ * If failure is catastrophic, you should know *how* and *why* it happened.
+ * Code should not be written in such a way that it won't work (at least in some fashion) if certain services or infrastructers are missing/different.
+ * Staging should be identical to production.
+ * Run Solr or RabbitMQ on staging, but not dev.
+ * Don't overdo it on logging.
+.. note:: Code not tested is broken by design