-
Notifications
You must be signed in to change notification settings - Fork 3
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(template): refactor and split code for test helper #317
fix(template): refactor and split code for test helper #317
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Current dependencies on/for this PR:
This stack of pull requests is managed by Graphite. |
} | ||
|
||
describe('FieldPluginExammple', () => { | ||
describe('FieldPluginExample', () => { | ||
afterEach(() => { | ||
vi.unstubAllGlobals() |
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.
After working closely on the test helper, I realized that we will need to provide additional documentation, maybe a comment that explains that vi.unstubAllGlobals() is needed if they use our helper setup()
function. This at first glance might be rather unintuitive.
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.
Good point! Maybe we could do
test('something', async () => {
const { cleanUp } = setupFieldPlugin();
// do stuff
cleanUp();
});
And cleanUp
is actually just vi.unstubAllGlobals()
internally. What do you think?
…oved console.logs
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.
Yeah I see vi.mock
can be tricky to abstract because of hoisting. I guess if we still took the approach #2, we could've done something like..
// something.spec.tsx
import { mockedLibrary } from '@storyblok/field-plugin/test'
vi.mock('@storyblok/field-plugin', mockedLibrary());
meaning it's the user who needs to mock the library while we provide the mock implementation. However, the approach #1 (the current PR) seems cleaner for users than that 🙂
} | ||
|
||
describe('FieldPluginExammple', () => { | ||
describe('FieldPluginExample', () => { | ||
afterEach(() => { | ||
vi.unstubAllGlobals() |
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.
Good point! Maybe we could do
test('something', async () => {
const { cleanUp } = setupFieldPlugin();
// do stuff
cleanUp();
});
And cleanUp
is actually just vi.unstubAllGlobals()
internally. What do you think?
What?
In this PR, I have refactored and separated the test helper PoC code into a separate file. I used the first approach #307 as it was easier to split.
Once the PR #313 is merged, I will continue with the following next steps:
packages/helpers/test
test
inside field-plugin exports in package.jsonWhy?
EXT-2078
How to test? (optional)
yarn install
yarn test:template react