From 9133f711fe847ec81eed81ea36a92cafa7204f97 Mon Sep 17 00:00:00 2001 From: Dannon Baker Date: Fri, 21 Nov 2025 17:14:15 -0500 Subject: [PATCH] Update docs from Jest to Vitest Changed all testing documentation to reference Vitest instead of Jest, including test commands, mock examples, and VSCode debug config. --- client/README.md | 18 +++++------ client/docs/composables.md | 3 +- client/docs/providers-and-renderers.md | 2 +- .../docs/unit-testing/debugging-unit-tests.md | 31 +++++++++---------- client/docs/unit-testing/readme.md | 6 ++-- client/docs/unit-testing/strategies.md | 5 +-- client/docs/unit-testing/writing-tests.md | 12 +++---- doc/source/dev/writing_tests.md | 6 ++-- 8 files changed, 41 insertions(+), 42 deletions(-) diff --git a/client/README.md b/client/README.md index afa67060c0c..75e3ca1c30b 100644 --- a/client/README.md +++ b/client/README.md @@ -114,13 +114,13 @@ developer-facing API of your new code. ### Testing Technologies -[Galaxy uses Jest](https://jestjs.io/) for its client-side unit testing +[Galaxy uses Vitest](https://vitest.dev/) for its client-side unit testing framework. For testing Vue components, we use the [Vue testing utils](https://vue-test-utils.vuejs.org/) to mount individual components in a -test bed and check them for rendered features. Please use jest-based mocking -for isolating test functionality. +test bed and check them for rendered features. Please use Vitest's mocking +capabilities for isolating test functionality. ### Linting @@ -152,17 +152,17 @@ executing all the client tests: yarn test -##### Watch and rerun jest unit tests every time a source file changes +##### Watch and rerun unit tests every time a source file changes This is incredibly handy, and there are a host of options in the interactive -terminal this starts for executing Jest tests. +terminal this starts for executing Vitest tests. - yarn run jest-watch + yarn test:watch ##### Run only specified test files when a source file changes - yarn run jest-watch MyModule + yarn test:watch MyModule - yarn run jest-watch Dialog + yarn test:watch Dialog - yarn run jest-watch workflow/run + yarn test:watch workflow/run diff --git a/client/docs/composables.md b/client/docs/composables.md index f8208470057..51849f18dc8 100644 --- a/client/docs/composables.md +++ b/client/docs/composables.md @@ -75,9 +75,10 @@ const store = new Vuex.Store({ The second option is to mock the composable: ```js +import { vi } from "vitest"; import { useCurrentUser } from "@/composables/user"; -jest.mock("composables/user"); +vi.mock("composables/user"); useCurrentUser.mockReturnValue({ currentUser: {}, }); diff --git a/client/docs/providers-and-renderers.md b/client/docs/providers-and-renderers.md index 2637fcbf9f9..4db13420cac 100644 --- a/client/docs/providers-and-renderers.md +++ b/client/docs/providers-and-renderers.md @@ -125,7 +125,7 @@ mandatory markup, just one big empty slot. // Testing a renderless component import { shallowMount } from "@vue/test-utils"; -import { getLocalVue, waitForLifecyleEvent } from "tests/jest/helpers"; +import { getLocalVue, waitForLifecyleEvent } from "@tests/vitest/helpers"; import DoodadProvider from "./DoodadProvider"; describe("A renderless component", () => { diff --git a/client/docs/unit-testing/debugging-unit-tests.md b/client/docs/unit-testing/debugging-unit-tests.md index 74097ef365b..2f1798b2c82 100644 --- a/client/docs/unit-testing/debugging-unit-tests.md +++ b/client/docs/unit-testing/debugging-unit-tests.md @@ -7,18 +7,18 @@ parameters actually does. I've gone ahead and annotated all the options, hopefully this will save some time, at least until VS code updates its test extensions again. -#### To debug a single Jest test: +#### To debug a single Vitest test: -1. Open a jest test (a file that ends with \*.test.js) +1. Open a vitest test (a file that ends with \*.test.js or \*.vitest.test.js) 1. Make sure the test file is selected, especially if you have multiple files open. This process will fail confusingly and without obvious error if you have not launched the debugger with the - actual Jest test file selected, and it's easy to accidentally click into another file if you've + actual Vitest test file selected, and it's easy to accidentally click into another file if you've got a dozen open. 1. Place a breakpoint in the margin of the file. You can place breakpoints anywhere in your source, - but you must launch the debugger while the jest file is selected because that is where jest and - webpack will start compiling. Alternatively, you can manually override the selected file in the + but you must launch the debugger while the vitest file is selected because that is where vitest + will start compiling. Alternatively, you can manually override the selected file in the configuration definition, like if you're testing the same file over and over again and don't want to worry about selecting it. @@ -30,7 +30,7 @@ code updates its test extensions again. 1. Click on the "Run and Debug" tab from the vscode icons on the left and choose the sample launch configuration (defined below) from the dropdown "run and debug". Or just hit F5. -1. Wait a bit, for webpack to compile everything, eventually you should be able to hover over +1. Wait a bit, for vitest to compile everything, eventually you should be able to hover over variables near your breakpoint and see their values in the "Variables" section of the Run and Debug pane. @@ -41,28 +41,25 @@ code updates its test extensions again. "configurations": [ { "type": "node", - "name": "debug selected jest test", + "name": "debug selected vitest test", "request": "launch", - // launches version of jest from inside the node_modules + // launches version of vitest from inside the node_modules // this means you need to have run yarn first - "program": "${workspaceFolder}/client/node_modules/jest/bin/jest", + "program": "${workspaceFolder}/client/node_modules/vitest/vitest.mjs", "args": [ - // Alias -i. - // Normally jest opens up a bunch of workers to run all your tests faster - // but we don't want that right now. - "--runInBand", + // Run tests in a single thread for debugging + "--no-threads", - // finds jest config - "--config", - "${workspaceFolder}/client/tests/jest/jest.config.js", + // Run in watch mode so tests can be re-run + "--watch", // This is how vscode references the currently selected file "${file}" ], "cwd": "${workspaceFolder}/client", - // opens jest output in integrated terminal + // opens vitest output in integrated terminal "console": "integratedTerminal", // allows you to place breakpoints right in vscode's gutter diff --git a/client/docs/unit-testing/readme.md b/client/docs/unit-testing/readme.md index 3b6a456488a..a501fca7954 100644 --- a/client/docs/unit-testing/readme.md +++ b/client/docs/unit-testing/readme.md @@ -1,10 +1,10 @@ -[Galaxy uses Jest](https://jestjs.io/) for its client-side unit testing +[Galaxy uses Vitest](https://vitest.dev/) for its client-side unit testing framework. For testing Vue components, we use the [Vue testing utils](https://vue-test-utils.vuejs.org/) to mount individual components in a -test bed and check them for rendered features. Please use jest-based mocking -for isolating test functionality. +test bed and check them for rendered features. Please use Vitest's mocking +capabilities for isolating test functionality. ### Specific test scenarios & examples diff --git a/client/docs/unit-testing/strategies.md b/client/docs/unit-testing/strategies.md index d06353193c3..32e57a62576 100644 --- a/client/docs/unit-testing/strategies.md +++ b/client/docs/unit-testing/strategies.md @@ -37,11 +37,12 @@ export function theThingYouReallyCareAbout() { ```js static // myModule.test.js +import { vi } from "vitest"; import { theThingYouReallyCareAbout, redirectTo } from "./myModule"; -// calling jest.mock on the appropriate import path wraps the exports and gives +// calling vi.mock on the appropriate import path wraps the exports and gives // access to new testing methods like mockImplementation -jest.mock("./myModule"); +vi.mock("./myModule"); redirectTo.mockImplementation((url) => { console.log(`I would have gone to: ${url}`); }); diff --git a/client/docs/unit-testing/writing-tests.md b/client/docs/unit-testing/writing-tests.md index 3e9384973a7..681acb0ae3a 100644 --- a/client/docs/unit-testing/writing-tests.md +++ b/client/docs/unit-testing/writing-tests.md @@ -23,7 +23,7 @@ The other side of the same coin is to test _only_ the unit in question. If your component has a model that uses a service that touches Vuex, which then uses Axios to fetch some data -- don't test all that at once. Break things apart and mock functionality to isolate testing to units. End to end testing is a -separate thing that shouldn't be attempted using spec tests in Jest. +separate thing that shouldn't be attempted using spec tests in Vitest. Assume nobody cares _how_ your code works, we just need to know that the public API you designed _does_ work. If performance problems or new tech necessitate a @@ -31,12 +31,12 @@ re-write, these tests become a guide for the next implementation. ### Writing a test file -Jest will try to test any file ending in "\*.test.js". Please place your test +Vitest will try to test any file ending in "\*.test.js" or "\*.vitest.test.js". Please place your test files inside client/src folders right next to whatever files that they are testing. -Jest has extensive documentation on the expect API, mocking, and more on the -[official docs page](https://jestjs.io/docs/en/getting-started.html), which will +Vitest has extensive documentation on the expect API, mocking, and more on the +[official docs page](https://vitest.dev/guide/), which will be your best resource here. ```js static @@ -63,10 +63,10 @@ describe("some module you wrote", () => { }); ``` -### Check out the Jest helper functions +### Check out the Vitest helper functions We have created some [common helpers for common testing -scenarios](https://github.com/galaxyproject/galaxy/blob/dev/client/tests/jest/helpers.js). +scenarios](https://github.com/galaxyproject/galaxy/blob/dev/client/tests/vitest/helpers.js). ### Mocking API calls diff --git a/doc/source/dev/writing_tests.md b/doc/source/dev/writing_tests.md index 44b66709d0b..f44d4f40e0f 100644 --- a/doc/source/dev/writing_tests.md +++ b/doc/source/dev/writing_tests.md @@ -40,7 +40,7 @@ find the right documentation for a given test one wishes to write. - **Client/ES6** These tests should be placed in ``client/src`` directly and executed - via Jest. Checkout [Frontend/ES6 Unit Tests](#es6_unit) below for more + via Vitest. Checkout [Frontend/ES6 Unit Tests](#es6_unit) below for more information. - **Backend/Python** @@ -172,12 +172,12 @@ Detailed information on writing Galaxy client tests can be found in The client tests are run against each pull request to Galaxy using GitHub actions. If any of these tests fail, the pull request will be marked -red. This test suite is moderately prone to having tests fail that are +red. This test suite is moderately prone to having tests fail that are unrelated to the pull request being tested; if this test suite fails on a pull request with changes that seem to be unrelated to the pull request - ping the Galaxy committers on the pull request and request a re-run. The GitHub actions workflow definition for these tests is located in -``.github/workflows/jest.yaml`` below Galaxy's root. +``.github/workflows/client-unit.yaml`` below Galaxy's root. {#framework} ## Tool Framework Tests