Describe the bug
To be clear, this bug doesn't break functionality, but it does get really annoying sometimes. :)
Vitest extension shows lots of false positive expect(...).toEqual(...) mismatches when using partial schema checks.
For instance,
My expect statement makes use of expect.objectContaining.
But, unless the entire schema matches perfectly, the Vitest extension assumes these don't match:
The issue here is that the extension assumes that ObjectContaining != Object even when there is no actual issue with the equality test, making me think expect.objectContaining doesn't work here, or that there's actually a comparison issue (e.g., the object doesn't contain something required).
To be clear, the vitest package / commandline has no problem exclusively highlighting where the actual issue is:
Note that none of the ObjectContaining lines are marked in red/green because nothing is actually wrong with any of them.
Expected behavior
Vitest extension should only highlight in red the actual issues, to match the behavior of the commandline.
I'm guessing this occurs because Vitest extension is just using VSCode's built-in text-diffing system. I really think in the future it should be switched to something with better clarity (unless we can control the diff-editor diff-ing behavior :-?). At this point, it makes it really hard sometimes to see where the actual issues are.
Reproduction
Running this test with the Vitest extension easily reproduces the issue:
import { describe, expect, it } from "vitest";
describe("diffing issue example", () => {
it("should not show red for ObjectContaining", () => {
// arrange
const actual = [
{ x: 1, y: 2, z: 3 },
{ x: 3, y: 1, z: 2 },
{ x: 2, y: 3, z: 1 },
"wrong",
];
// act / assert
expect(actual).toEqual([
expect.objectContaining({ x: 1 }),
expect.objectContaining({ z: 2 }),
expect.objectContaining({ y: 3 }),
]);
});
});
Output
[4:32:53 PM] [API] Filtering projects: foo
[INFO 4:32:53 PM] [API] Running Vitest v3.0.7 (project/vitest.workspace.ts) with "D:\nodejs\node.EXE C:/Users/Me/.vscode/extensions/vitest.explorer-1.50.2/dist/worker.js"
[4:32:53 PM] Enqueuing "should not show red for ObjectContaining"
[INFO 4:32:53 PM] Running 1 file(s) with name pattern: ^\s?diffing issue example
[INFO 4:32:54 PM] [DECOR] Reset all decorations.
[4:32:54 PM] No task result for "test.test.ts [foo]", ignoring
[4:32:54 PM] No task result for "diffing issue example", ignoring
[4:32:54 PM] Enqueuing "should not show red for ObjectContaining"
[4:32:54 PM] No errors found for "test.test.ts [foo]"
[4:32:54 PM] No errors found for "diffing issue example"
[4:32:54 PM] Could not find a valid stack for should not show red for ObjectContaining [
{
"method": "",
"file": "D:/project/foo/test.test.ts",
"line": 14,
"column": 20
}
]
[4:32:54 PM] Marking "should not show red for ObjectContaining" as failed with 1 errors
[4:32:54 PM] Disposing test runner
[4:32:54 PM] Ending test run foo/test.test.ts
[4:32:54 PM] [API] Vitest WebSocket connection closed, cannot call RPC anymore.
Extension Version
vitest.explorer v1.50.2
Vitest Version
vitest@3.0.7
Validations
Describe the bug
To be clear, this bug doesn't break functionality, but it does get really annoying sometimes. :)
Vitest extension shows lots of false positive
expect(...).toEqual(...)mismatches when using partial schema checks.For instance,
My
expectstatement makes use ofexpect.objectContaining.But, unless the entire schema matches perfectly, the Vitest extension assumes these don't match:
The issue here is that the extension assumes that
ObjectContaining != Objecteven when there is no actual issue with the equality test, making me thinkexpect.objectContainingdoesn't work here, or that there's actually a comparison issue (e.g., the object doesn't contain something required).To be clear, the
vitestpackage / commandline has no problem exclusively highlighting where the actual issue is:Note that none of the
ObjectContaininglines are marked in red/green because nothing is actually wrong with any of them.Expected behavior
Vitest extension should only highlight in red the actual issues, to match the behavior of the commandline.
I'm guessing this occurs because Vitest extension is just using VSCode's built-in text-diffing system. I really think in the future it should be switched to something with better clarity (unless we can control the diff-editor diff-ing behavior :-?). At this point, it makes it really hard sometimes to see where the actual issues are.
Reproduction
Running this test with the Vitest extension easily reproduces the issue:
Output
Extension Version
vitest.explorer v1.50.2
Vitest Version
vitest@3.0.7
Validations