-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Testing Style to Contributing docs #217
Add Testing Style to Contributing docs #217
Conversation
If anyone has more ideas of what we can/should add to this documentation, please let me know. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is wonderful! love that we can already use our tests as examples
this is a great start! we can iterate on this as we go
anyone has any ideas around test() vs it()? i like it() more, but at the same time dont feel like it should be mandatory to use one or the other? |
We already have hundreds of tests using |
|
||
* Use the `describe` blocks to split up logically related tests, and write clear descriptions of what the tests relate to. (See tests in the [`base-entity`](https://github.com/ViacomInc/data-point/blob/b60824509467af599ef12d730a1b6cf8778d0b9d/packages/data-point/lib/entity-types/base-entity/resolve.test.js#L216) for an example.) | ||
* Break up individual tests to have as few `expect`s in each test as possible. This way if a single `expect` fails for some reason, it immediately gets narrowed down to the one test that failed. Also when `jest` throws the error it'll write the description string in the console, so we'll be able to read the English description of what failed and not read any code to understand the problem. (See [these tests in `reducer-herlpers/utils`](https://github.com/ViacomInc/data-point/blob/b60824509467af599ef12d730a1b6cf8778d0b9d/packages/data-point/lib/reducer-types/reducer-helpers/utils/index.test.js#L5-L45) for an example.) | ||
* Write simple result expectations directly in the test. Use `toMatchSnapshot()` if there is a large, complex expected result. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might also be good to mention toThrowErrorMatchingSnapshot
- I've definitely found that useful when attaching custom data/messages to an error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great point, thanks!
Added a bullet below this one about writing tests for failures and mentioning toThrowErrorMatchingSnapshot
as a way to do this.
I also like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you thanks thank you!!
What: Adds Testing Style section to CONTRIBUTING.md
Why: To make it easier for contributors to write quality tests that clearly explain the codebase.
How: Typing and copying from the comments on #207.
Checklist: