-
Notifications
You must be signed in to change notification settings - Fork 224
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
Use Vitest and expect methods for testing suite #1245
Conversation
29f535e
to
9e4bf4c
Compare
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 great! Thank you @yeoffrey! 🙌
I would change the throws/doesNotThrow calls as well. Unless we really have to, I would avoid special cases and exceptions — I doubt that new contributors would realise that we use assert
for error handling, but Vitest for everything else.
I tested this snippet and it seems to print almost the same exact message like assert
, so I don't think we're losing any more functionality.
it('custom error message', () => {
expect(() => string().create(42, 'Not a string!')).toThrow(
expect.objectContaining({
message: 'Not a string!',
cause: 'Expected a string, but received: 42',
})
)
})
- CallTracker has been deprecated in Node.js - vi.fn() is probably more familiar to Vitest users
* Use vitest except where possible and organize tests * Use vi.fn() instead of CallTracker in 'deprecated' helper - CallTracker has been deprecated in Node.js - vi.fn() is probably more familiar to Vitest users --------- Co-authored-by: Artur Müller <me@arturmuller.com>
* Use vitest except where possible and organize tests * Use vi.fn() instead of CallTracker in 'deprecated' helper - CallTracker has been deprecated in Node.js - vi.fn() is probably more familiar to Vitest users --------- Co-authored-by: Artur Müller <me@arturmuller.com>
In this PR, the test suite has been modified:
deepStrictEqual
anddeepEqual
have been changed to.toStrictEqual
for objects and arrays and.toBe
for literals.throws
anddoesNotThrow
because it offers a nicer api to check whether an error was thrown or not than the Jestyexpect
solution.#1244