dce/davideisinger.com
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

More testing notes

Browse Source
This commit is contained in:
David Eisinger
2023-05-22 23:05:57 -04:00
parent 4460dd01b1
commit 1914a15623
1 changed files with 12 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
content/notes/good-tests/index.md
View File

@@ -7,6 +7,11 @@ draft: false
_(Notes for a Viget article I'm putting together)_ _(Notes for a Viget article I'm putting together)_
* Most importantly: **give you confidence to make changes** * 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 * Focus on two kinds of tests: unit and integration
* Unit: test your objects/functions directly * Unit: test your objects/functions directly
* Integration: simulated browser interactions * 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! * 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 * 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 * 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 * Third-party/network calls
* Major libraries often have mock services (e.g. [stripe-mock][2]) * Major libraries often have mock services (e.g. [stripe-mock][2])
* VCR is … OK but can become a maintenance problem * 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 * A better approach
* Move your integration code into a module * Move your integration code into a module
* Create a second stub module with the same API * 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 * This will lead to more reliable tests and also more robust code
* Flaky tests are bad * Flaky tests are bad
* They eat up a lot of development time (esp. as build times increase) * 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 * 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) * 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 * 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 * So write better code or pick better tools
[3]: https://json-schema.org/
[1]: https://en.wikipedia.org/wiki/Test-driven_development [1]: https://en.wikipedia.org/wiki/Test-driven_development
[2]: https://github.com/stripe/stripe-mock [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" />}} {{<thumbnail notes "400x" />}}