switch from jest to vitest #5022
Conversation
|
There was a problem hiding this comment.
I'd like to block this on updating the VS Code launch.json script. It's essential to my workflow.
Extra questions:
- Does Vitest have an interactive watch mode in which I could filter tests using filenames or/and test names?
- If yes, does it have something akin to
jest-watch-typehead?
Yes; here is an example in
|
I've got you buddy 🤗 |
@Andarist Wanna test it locally and make sure it's working the way you expect? |
|
I noticed it's fairly easy to lose those typeahead filters in watch mode (for example pressing Enter clears them). It's annoying but not a big deal. When debugging with VS Code, I can't disable source mapped stepping - it still shows me a location in the source file (albeit a different/broken one). This is way more annoying, probably something I can live with but well. I just wish that console evaluation could use original references, is this too much to ask for? 😭 😭 😭 (to clarify, this is just something that current debuggers suck at cause they are not utilizing sourcemapped info to its full extent) |
Yeah for some reason they chose to use |
| after: { | ||
| 10: '#end' | ||
| it('should be able to transition with delay from nested initial state', () => | ||
| new Promise<void>((resolve) => { |
There was a problem hiding this comment.
Those kind of changes could probably be replaced with async functions and waitFor. Some might not be but then I'd go with Promise.withResolvers (which might not be available in our testing envs, I'm not sure). This would allow u to create a deferred thing at the top of the async function, await it at the bottom before ur expect calls and .resolve/.reject it from callbacks. This would avoid adding extra indentation to the tests that got refactored by introducing new Promise
There was a problem hiding this comment.
imo the new Promise callback style works well for assertion-free tests (where the test is basically just that it doesn't time out (because resolve was called)). Plus it's the closest to the old done callback style (minus the extra indentation).
I think this example shows the pitfalls of waitFor/Promise.withResolvers with this style of test:
test('new Promise', () =>
new Promise((resolve) => {
const machine = createMachine({
initial: 'waiting',
states: {
waiting: {
after: {
10: 'done'
}
},
done: {
entry: resolve
}
}
});
createActor(machine).start();
// no assertions or other logic necessary. the test only passes if the
// promise resolves; otherwise, it times out
}));
test('waitFor', async () => {
const machine = createMachine({
initial: 'waiting',
states: {
waiting: {
after: {
10: 'done'
}
},
done: {}
}
});
const actor = createActor(machine);
actor.start();
// we need to wait for + assert the transition. if we forget to `await` or
// forget `waitFor` entirely, the test passes even though we haven't actually
// tested anything
await waitFor(actor, (snapshot) => snapshot.matches('done'));
});
test('Promise.withResolvers', () => {
const { promise, resolve } = Promise.withResolvers();
const machine = createMachine({
initial: 'waiting',
states: {
waiting: {
after: {
10: 'done'
}
},
done: {
entry: resolve
}
}
});
createActor(machine).start();
// if we don't `await promise` or `return promise`, the test passes even
// though `resolve` isn't called. would be an easy mistake to make and the
// cost is that the test isn't actually testing anything even though it's
// passing
return promise;
});Maybe not a big deal since it's something that could be caught in code review, but is it worth it just to avoid extra indentation?
Though actually now that I'm thinking about it, maybe we shouldn't have assertion-free tests to begin with 🙃
Definitely agree with waitFor/Promise.withResolvers for tests where we're actually making assertions and such though. I'll convert those over.
There was a problem hiding this comment.
Though actually now that I'm thinking about it, maybe we shouldn't have assertion-free tests to begin with 🙃
This. I think it's always best to assert something explicitly. That always gives some extra insight to what is actually being tested
|
Just wanted to plug Wallaby for running tests in "watch" mode (or even as you type). I've been a user for years and I haven't found anything better. |
This PR switches our test setup from
jesttovitest.How it's configured
vitest.workspace.jsondefines our workspaces as["packages/*"].vitestlooks for avitest.configfile in each workspace and uses it to run that workspace's tests. This allows each workspace to define the plugins (likevite-plugin-solidfor@xstate/solid) and test configuration used to run that workspace's tests.This allows us to run tests for specific workspaces using
vitest --project <package name>(vitest --project @xstate/react).Major changes
jestdependencies (11❗), configs, scripts, etc.jsdomwithhappy-domdonecallbacks withnew Promisecallbacks +resolveviteplugins to some packages for out-of-the-box support in tests@xstate-repo/jest-utilspackagetoMatchMockCallsInlineSnapshotwithtoMatchInlineSnapshot(vitestdoesn't support wrapping snapshot functions the way we could withjest-snapshot)spyOnConsolewith inlineconsolespies for the tests that require itsleepwithsetTimeoutfromnode:timers/promises