[Test Migration] Pt 2 - move packages/core from Karma to Vitest#7709
[Test Migration] Pt 2 - move packages/core from Karma to Vitest#7709cameronjoyner wants to merge 32 commits intodevelopfrom
packages/core from Karma to Vitest#7709Conversation
Generate changelog in
|
ran pnpm format on overlay2TestsBuild artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
noEmit and skipLibCheckBuild artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
further simplicationsBuild artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
packages/core from Karma to Vitestpackages/core from Karma to Vitest
| import { sleep } from "../utils"; | ||
|
|
||
| describe("<ResizeSensor>", () => { | ||
| describe.skip("<ResizeSensor>", () => { |
There was a problem hiding this comment.
Do we have a plan for how we should implement these sorts of tests that are more reliant on web APIs?
centralize dependencies in one locationBuild artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
central namingBuild artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
| export function createBlueprintVitestConfig(options: BlueprintVitestOptions = {}) { | ||
| const { include = ["test/**/*Tests.{ts,tsx}"], exclude = [], includeEnzyme = true } = options; | ||
|
|
||
| const setupFile = includeEnzyme | ||
| ? "@blueprintjs/test-commons/vitest.setup" | ||
| : "@blueprintjs/test-commons/vitest-setup-no-enzyme"; | ||
|
|
||
| return defineConfig({ | ||
| plugins: [react()], | ||
| test: { | ||
| environment: "jsdom", | ||
| exclude: ["lib/**", "node_modules/**", ...exclude], | ||
| include, | ||
| setupFiles: setupFile, | ||
| }, | ||
| }); | ||
| } |
fixing lintBuild artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
prettierBuild artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
linter error + vitest coverageBuild artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
packages/core from Karma to Vitestpackages/core from Karma to Vitest
0c9c0a3 to
f193ff3
Compare
Compressing to one commitBuild artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
f193ff3 to
31b9646
Compare
pnpm installBuild artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
fix lintBuild artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
| it("renders hotkey label", () => { | ||
| render(<Hotkey combo="cmd+C" label="test copy me" group="editing" />); | ||
| expect(screen.getByText("test copy me")).not.to.be.undefined; | ||
| expect(screen.getByText("test copy me")).to.not.be.undefined; |
There was a problem hiding this comment.
nit: Similar to above, I think this would be better described by:
| expect(screen.getByText("test copy me")).to.not.be.undefined; | |
| expect(screen.getByText("test copy me")).toBeInTheDocument(); |
| "lib": ["dom", "dom.iterable", "es5", "es2015.collection", "es2015.iterable", "es2015.promise"], | ||
| "noEmit": true | ||
| "noEmit": true, | ||
| "skipLibCheck": true |
There was a problem hiding this comment.
Similar to the last PR, is there anything necessitating these changes to the tsconfig.json files? Is this needed?
There was a problem hiding this comment.
Ok I added this back and want to reopen the discussion. I did this today to skip type-checking for .d.ts files.
I believe this has to do with moduleResolution.
In /core/src/design-tokens/tsconfig.json: "moduleResolution": "Bundler",
In /config/tsconfig.web.json: "moduleResolution": "node",
In /config/tsconfig.node.json: "moduleResolution": "node16",
packages/core/test/tsconfig.json
└── extends: ../src/tsconfig.json
└── extends: config/tsconfig.web.json
Still investigating. It seems that use of bundler is partially to blame for this.
packages/core/package.json
Outdated
| "enzyme": "^3.11.0", | ||
| "karma": "^6.4.2", | ||
| "@vitejs/plugin-react": "catalog:", | ||
| "@vitest/coverage-v8": "catalog:", |
There was a problem hiding this comment.
Where is the @vitest/coverage-v8 dep used? Should it be included in the test-commons deps?
responding to usage of toBeInTheDocumentBuild artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
dedupeBuild artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
addressing usage of after() and before()Build artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
| * Licensed under the Apache License, Version 2.0 (the "License"); | ||
| */ | ||
|
|
||
| /// <reference types="@testing-library/jest-dom/vitest" /> |
There was a problem hiding this comment.
@ggdouglas I haven't worked a ton with *.d.ts files and am wondering if this file is unnecessarily exporting export { test, it, beforeAll, afterAll, describe, beforeEach, afterEach, expect, assert, vi } from "vitest";
There was a problem hiding this comment.
I don't think that I can use /// <reference types="@testing-library/jest-dom/vitest" /> in a normal .ts file
removing a dep from package.jsonBuild artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
removing unused dep from /coreBuild artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
skip type-checking of declaration files (.d.ts)Build artifact links for this commit: documentation | landing | table | demoThis is an automated comment from the deploy-preview CircleCI job. |
Background
Why Vitest instead of Karma?
Karma is a tool that allows you to execute JavaScript code in multiple real browsers. It was deprecated in April of 2023 and they even recommend moving to
JestorVitest. Online you can find folks who maintain similar products pondering which to switch to [example 1, example 2]Vitest’s documentation claims that their product can live in harmony withJest, however it would be duplicative. They claim:Moving away from Karma also aligns with the precedent set in packages/labs
Why not Jest?
Vitest intentionally mirrors Jest's API (
describe,it,expect, mocking, etc), runs faster, and includes a built-in UI for browsing test results, better inline snapshots, and native support for features like concurrent test executionWhy move off of Chai?
Mocha is a test framework running on Node.js and in the browser. Mocha is a popular choice for server-side testing. Mocha is highly configurable and does not include certain features by default. For example, it does not come with an assertion library, which is why we use the popular
Mochaassertions complement, Chai.We originally introduced it in #1741, 8 years ago. I don’t see its usage/existence as a bad thing, but by moving off of
Chaiwe may be able to naturally move off ofMocha.Differences between Labs and Core
*Tests.tsx*.test.tsxFLUPs to this PR
Move tests to adhere to colocation standards in
/labsthen migrate other packages tovitest, rinse, repeatChanges proposed in this pull request:
Migrate
packages/corefrom Karma to VitestMust give due credit to Greg's initial exploration in
gdouglas/vitest-experiment