From 4460dd01b1c9937e44cbbaef13cd62546d7ab77a Mon Sep 17 00:00:00 2001 From: David Eisinger Date: Mon, 22 May 2023 22:51:23 -0400 Subject: [PATCH] Misc. good test thoughts --- content/notes/good-tests/index.md | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/content/notes/good-tests/index.md b/content/notes/good-tests/index.md index 65b3aaa..9cf1945 100644 --- 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 {{}}