-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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(core): test change should trigger failed test rerun #3773
base: main
Are you sure you want to change the base?
Conversation
Run & review this pull request in StackBlitz Codeflow. |
✅ Deploy Preview for fastidious-cascaron-4ded94 canceled.
|
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.
- Add test case to
test/watch/test/stdin.test.ts
- The implementation doesn't seem to consider the filter enabled by pressing
f
? This PR should only affect that use case.
Maybe I misunderstood you guys? I thought that as long as the test content is modified, if there is a failed test case, it will automatically rerun. I seem to understand that only after pressing |
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.
Maybe I misunderstood you guys? I thought that as long as the test content is modified, if there is a failed test case, it will automatically rerun.
I seem to understand that only after pressing
f
, if the content of the test file is modified, the failed test will be automatically run, is it?
The issue contains two bugs:
- When user has activated "Run only failed test"-filter in watch mode by pressing
f
, this filter does not preserve if files are modified - The "Run only failed test"-filter runs all test cases inside test files. It should run only failed test cases. Now it's only filtering the files.
@@ -27,6 +27,40 @@ test('rerun current pattern tests', async () => { | |||
await vitest.waitForStdout('1 passed') | |||
}) | |||
|
|||
test('rerun failed tests', async () => { |
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.
We'll need a test case that fails in main
, and is fixed by these changes. This test case does not fail on main
branch.
Maybe something like below?
test('rerun failed tests', async () => {
const testPath = 'fixtures/error.test.ts'
const failAssertion = 'expect(1).toBe(2)'
const testCase = `// Dynamic test case
import { test, expect } from 'vitest'
// Failure re-run should run this
test('failing test', () => {
${failAssertion}
})
// Failure re-run should NOT run this
test('passing test', () => {
expect(1).toBe(1)
})
`
writeFileSync(testPath, testCase, 'utf8')
cleanups.push(() => rmSync(testPath))
const vitest = await runVitestCli(...cliArgs)
await vitest.waitForStdout('Test Files 1 failed | 2 passed (3)')
await vitest.waitForStdout('Tests 1 failed | 3 passed (4)')
// Re-run failed tests only
vitest.write('f')
// Only a single test should have run
await vitest.waitForStdout('Test Files 1 failed (1)')
// Only a single test case should have run
await vitest.waitForStdout('Tests 1 failed (1)')
// Fix failing test case
writeFileSync(testPath, testCase.replace(failAssertion, ''), 'utf8')
// Only the previously failed test file should run
await vitest.waitForStdout('Test Files 1 pass (1)')
// Only the previously failed test case should run
await vitest.waitForStdout('Tests 1 pass (1)')
})
@@ -76,14 +76,20 @@ export function registerConsoleShortcuts(ctx: Vitest) { | |||
if (name === 'u') | |||
return ctx.updateSnapshot() | |||
// rerun all tests | |||
if (name === 'a' || name === 'return') | |||
if (name === 'a' || name === 'return') { | |||
ctx.isFailedModel = false |
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.
I don't think we should set properties of ctx
outside it like this. Could this filter be toggled on/off inside the core.ts
instead?
But your approach is right in the way that we indeed need to save the failure filter in state.
If I didn't understand the error, it means that if a test file has test cases that fail, after pressing And if the content of the file is modified, the failed test will not be filtered, and the original operation logic can be followed. |
I'm not 100% sure, but the changes should be made somewhere around |
Sorry, I can't seem to find any relevant instructions in the official documentation. Maybe I'm missing something. 🤔 @sheremet-va Can you give me a little hint? Thanks! |
I'm not sure, but I think you can set |
fix #3687