opensource/galaxy
3
0
Fork 0
mirror of https://github.com/galaxyproject/galaxy.git synced 2026-08-30 16:58:03 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update docs from Jest to Vitest

Browse Source 
Changed all testing documentation to reference Vitest instead of Jest,
including test commands, mock examples, and VSCode debug config.
This commit is contained in:
Dannon Baker
2025-11-21 17:14:15 -05:00
parent c7560c5511
commit 9133f711fe
8 changed files with 41 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files
client/README.md
+9 -9
View File
@@ -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
client/docs/composables.md
+2 -1
View File
@@ -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: {},
});
client/docs/providers-and-renderers.md
+1 -1
View File
@@ -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", () => {
client/docs/unit-testing/debugging-unit-tests.md
+14 -17
View File
@@ -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
client/docs/unit-testing/readme.md
+3 -3
View File
@@ -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
client/docs/unit-testing/strategies.md
+3 -2
View File
@@ -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}`);
});
client/docs/unit-testing/writing-tests.md
+6 -6
View File
@@ -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
doc/source/dev/writing_tests.md
+3 -3
View File
@@ -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