Update testing note
This commit is contained in:
@@ -7,19 +7,31 @@ 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**
|
||||||
* You need proper end-to-end testing
|
* Focus on two kinds of tests: unit and integration
|
||||||
|
* Unit: test your objects/functions directly
|
||||||
|
* Integration: simulated browser interactions
|
||||||
|
* If you're building an API, you might also have request specs
|
||||||
|
* But ideally you're testing the full integration of UI + API
|
||||||
|
* Unit tests
|
||||||
|
* Put complex logic into easily testable objects/functions
|
||||||
|
* Avoid over-stubbing/mocking -- what are you even testing
|
||||||
|
* Integration tests
|
||||||
|
* You need proper end-to-end testing
|
||||||
* Set up your data (fresh per test)
|
* Set up your data (fresh per test)
|
||||||
* Visit a page
|
* Visit a page
|
||||||
* Interact with it
|
* Interact with it
|
||||||
* Make assertions about the results
|
* Make assertions about the results
|
||||||
* Put complex logic into easily testable objects/functions
|
|
||||||
* Create stub objects to stand in for network calls
|
* Create stub objects to stand in for network calls
|
||||||
* Use [JSON Schema][1] to ensure stub stays in sync
|
* Use [JSON Schema][1] to ensure stub stays in sync
|
||||||
* Avoid over-stubbing/mocking
|
|
||||||
* Coverage
|
* Coverage
|
||||||
* We shoot for 100% in SimpleCov (So all the Ruby is tested)
|
* We shoot for 100% in SimpleCov (So all the Ruby is tested)
|
||||||
* Some consider this too high or too burdensome -- I don't
|
* Some consider this too high or too burdensome -- I don't
|
||||||
* 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
|
||||||
|
* 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
|
||||||
|
|
||||||
[1]: https://json-schema.org/
|
[1]: https://json-schema.org/
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user