commit 4460dd01b1c9937e44cbbaef13cd62546d7ab77a
parent 882fbe0bfcb6e6e69044c4035f199a4a6844d7ac
Author: David Eisinger <[email protected]>
Date: Mon, 22 May 2023 22:51:23 -0400
Misc. good test thoughts
Diffstat:
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/content/notes/good-tests/index.md b/content/notes/good-tests/index.md
@@ -14,19 +14,15 @@ _(Notes for a Viget article I'm putting together)_
* But ideally you're testing the full integration of UI + API
* Unit tests
* Put complex logic into easily testable objects/functions
+ * This is where [TDD][1] can come into play
* Avoid over-stubbing/mocking -- what are you even testing
+ * It is OK to go down the stack in your unit tests
* Integration tests
* You need proper end-to-end testing
* Set up your data (fresh per test)
* Visit a page
* Interact with it
* Make assertions about the results
-* Third-party/network calls
- * VCR is … OK but can become a maintenance problem
- * Block access to the web
- * Create stub objects to stand in for network calls
- * Use [JSON Schema][1] to ensure stub stays in sync
- * This will lead to more reliable tests and also more robust code
* Coverage
* We shoot for 100% in SimpleCov (So all the Ruby is tested)
* Some consider this too high or too burdensome -- I don't
@@ -34,12 +30,24 @@ _(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
+* 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
+ * 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)
+ * 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)
* 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
-[1]: https://json-schema.org/
+[3]: https://json-schema.org/
+[1]: https://en.wikipedia.org/wiki/Test-driven_development
+[2]: https://github.com/stripe/stripe-mock
{{<thumbnail notes "400x" />}}
