Skip to content
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

Fix typo Update README.md #7819

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion packages/wallet/src/test/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -129,7 +129,7 @@ To mock query resolvers in tests we can use the helper function `queryResolvers`

The usage of the `queryResolvers` function is not mandatory, because we can mock resolvers without this function, but it has a few benefits:

1. In cases where queries select only a subset of document fields (e.g. `address` and `id` from the `Token` type without other properties, such as `chain`, etc.), it will automatically filter out unnecessary fields from the query response and we will get the object of shape exactly the same as specified in the query document. Without the usage of the `queryResolvers` function, responses will contain all fields of the fixture we returned from our custom resolvers, which lead to unpredictible results in some tests.
1. In cases where queries select only a subset of document fields (e.g. `address` and `id` from the `Token` type without other properties, such as `chain`, etc.), it will automatically filter out unnecessary fields from the query response and we will get the object of shape exactly the same as specified in the query document. Without the usage of the `queryResolvers` function, responses will contain all fields of the fixture we returned from our custom resolvers, which lead to unpredictable results in some tests.
2. It makes it possible to access values returned from resolvers. This is especially useful, when queries select specific fields and we want to expect test result based on what was returned from the resolver (not based on the fixture with all fields, some of which weren't present in the query response),
3. The writing of custom resolvers in tests is cleaner with `queryResolvers` and requires less code (no need to create `Query` object with resolvers, we can pass just resolvers without the `Query` object)

Expand Down