ardatan / ardatan/graphql-tools

`@graphql-tools/mock` - controllable randomness when mocking out union types

Open
#5,614 0 comments 1 reaction 0 assignees View on GitHub
Dominant language
TypeScript
Stars
5.4k
Forks
830
Avg merge
10h 59m
Merged PRs (30d)
45

Description

**Is your feature request related to a problem? Please describe.**

Hello, we are using `@graphql-tools/mock` in our unit and functional testing. It works well for most parts; however, we recently discovered that the default mocks for union types are generated randomly, which means the mocked value could change from one test run to another. If an engineer isn't aware that a field is a dependency or even a sub-dependency of their module, it's possible to have a flaky test.

For example, given a union type like
```
union A = B | C | D;
```
The resolved type of `A` is completely unpredictable(can be B, C, or D) between different test runs. We believe this behavior is due to this [takeRandom](https://github.com/ardatan/graphql-tools/blob/master/packages/mock/src/MockStore.ts#L540) call

**Describe the solution you'd like**
It would be nice if we can add an extra control to the `addMocksToSchema` function. Something like `fixedUnionType: boolean`. If the flag is true, we also return the first subtype from a union and generate mocks for it. In the above example, if `fixedUnionType` is true, `A` would always resolve to `B`.

**Describe alternatives you've considered**
We could ask our engineers to always provide a mock override when dealing with union types. However, this solution might be unrealistic, even at a small scale, since a component might consume many fields, and providing mocks for everything would be a heavyweight task.

**Additional context**

Contributor guide

Open the contributing guide

Research direction

Start in packages/mock/src/MockStore.ts around the takeRandom call mentioned in the issue, then trace how addMocksToSchema configures mock behavior. Define how the proposed control should select a union subtype and verify that enabled mocking consistently resolves the first subtype while existing behavior remains available.

Written by the indexing model from the issue text.

Assessment

Tech stack
graphql, typescript
Domain
api, testing
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.