diff --git a/content/notes/good-tests/index.md b/content/notes/good-tests/index.md
index 9cf1945..712a21e 100644
--- a/content/notes/good-tests/index.md
+++ b/content/notes/good-tests/index.md
@@ -7,6 +7,11 @@ draft: false
 _(Notes for a Viget article I'm putting together)_
 
 * Most importantly: **give you confidence to make changes**
+  * This gets more and more important over time
+* Secondarily:
+  * Tells you it works during development
+  * Help your code reviewers
+  * Serves as a kind of documentation (though not a very concise one)
 * Focus on two kinds of tests: unit and integration
   * Unit: test your objects/functions directly
   * Integration: simulated browser interactions
@@ -30,24 +35,28 @@ _(Notes for a Viget article I'm putting together)_
     * If it's, say, 94%, and you add 100 lines, six of those can be untested -- hope they're perfect!
     * In other words, at less than 100% coverage, you don't know if your new feature is fully covered or not
   * Occasionally you have to ignore some code -- e.g. something that only runs in production
+  * It's OK if you're not at 100% right now -- set the threshold to your current level, and increase it as you add tests and new well-tested features
 * Third-party/network calls
   * Major libraries often have mock services (e.g. [stripe-mock][2])
   * VCR is … OK but can become a maintenance problem
-    * Block access to the web
+    * Blocking access to the web is good though -- [webmock][3]
   * A better approach
     * Move your integration code into a module
     * Create a second stub module with the same API
-    * Use [JSON Schema][3] to ensure stub stays in sync (i.e. both the real client and the stub client validate against the schema)
+    * Use [JSON Schema][4] to ensure stub stays in sync (i.e. both the real client and the stub client validate against the schema)
     * This will lead to more reliable tests and also more robust code
 * Flaky tests are bad
   * They eat up a lot of development time (esp. as build times increase)
   * Try to stay on top of them and squash them as they arise
   * Some frameworks have `retry` options/libraries that can help (bandage not cure)
+    * [rspec-retry][5]
   * In general, though, flaky tests suck and generally indicate lack of quality with either your code or your tools
     * So write better code or pick better tools
 
-[3]: https://json-schema.org/
 [1]: https://en.wikipedia.org/wiki/Test-driven_development
 [2]: https://github.com/stripe/stripe-mock
+[3]: https://github.com/bblimke/webmock#real-requests-to-network-can-be-allowed-or-disabled
+[4]: https://json-schema.org/
+[5]: https://github.com/NoRedInk/rspec-retry
 
 {{<thumbnail notes "400x" />}}