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

feat(test-utils): work with either jest or vitest #5692

Closed

Conversation

eventualbuddha
Copy link
Collaborator

@eventualbuddha eventualbuddha commented Dec 5, 2024

Overview

Follow-up to #5690.

Changes @votingworks/test-utils to look for either a jest global or import from vitest, mostly for creating mock functions (i.e. fn). For simplicity, keeps the jest API for mock functions because they're so similar (but not actually TS-compatible). The possibility of importing whenever we call fn within test-utils means that anything that creates a mock function now needs to be async. This isn't awesome and it caused a bunch of changes in other packages, but I think it's worth it to allow the jestvitest migration to occur in pieces.

Demo Video or Screenshot

n/a

Testing Plan

Automated tests.

Follow-up to #5690.

Changes `@votingworks/test-utils` to look for either a `jest` global or import from `vitest`, mostly for creating mock functions (i.e. `fn`). For simplicity, keeps the `jest` API for mock functions because they're so similar (but not actually TS-compatible). The possibility of `import`ing whenever we call `fn` within `test-utils` means that anything that creates a momck function now needs to be async. This isn't awesome and it caused a bunch of changes in other packages, but I think it's worth it to allow the `jest` → `vitest` migration to occur in pieces.
console[method]('test');
expect(console[method]).toHaveBeenNthCalledWith(1, 'test');
});
expect('mock' in console[method]).toEqual(false);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may still be true with vitest, but felt like testing an implementation detail. Replaced it with what we actually care about.

expect('mock' in console.log).toEqual(false);
});

test('suppressingConsoleOutput throws the error thrown by the callback', () => {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that suppressingConsoleOutput always returns a Promise, this test is redundant.

Comment on lines -141 to +147
jest.spyOn(console, 'log').mockRestore();
jest.spyOn(console, 'warn').mockRestore();
jest.spyOn(console, 'error').mockRestore();
logSpy.mockRestore();
warnSpy.mockRestore();
errorSpy.mockRestore();
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seeming behavior difference: jest uses the original spy with this second spyOn call, then restores it. vitest seems to replace the first spy with a second spy, then immediately restores back to the first spy.

None of the tests actually require a DOM, so this simplifies the test setup.
For some reason this causes `vitest` to fail and report almost all coverage as 0.
@eventualbuddha
Copy link
Collaborator Author

Closing in favor of #5703.

@eventualbuddha eventualbuddha deleted the brian/test/test-utils/vitest branch December 10, 2024 01:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant