12ab93d9e0
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #33173 # Details This PR updates the "Setting up your device" page which appears in Linux and Windows (and as of https://github.com/fleetdm/fleet/issues/30117, MacOS) setup experiences. Front-end updates: * Lots of renaming of things that were software-specific to now more generically refer to "setup step" * Removed the "My Device" heading * Moved the info button inside the table header * Added status of setup script run to the table * Updated the empty state to not refer specifically to software * Added optional `setup_only` query param to the `/device` page which, if set, will always show the "setting up your device" page even if all setup is complete. Normally as soon as setup finishes, the front-end redirects to the regular My Device page. In the case of MacOS setup experience, we don't want this to happen as we expect to either 1) keep the setup experience up indefinitely if we're blocking device setup on software install failure, or 2) close the setup dialog on successful completion. This query param is also handy for testing. * Added new "Configuration complete" state to be shown when all setup steps are finished (successfully or not). This is only applicable on MacOS, since other platforms will redirect to the My Device page when finished. This PR also includes one small backend change to the `/device/{token}/setup_experience/status` API endpoint, to have it return a `scripts` array alongside the existing `software` array. This endpoint is not documented publicly. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files) for more information. ## Testing - [X] Added/updated automated tests Updated existing DeviceUserPage tests that check the SettingUpYourDevice content, and added new tests for the new scripts content and the new query param. - [X] QA'd all new/changed functionality manually <img width="1028" height="867" alt="Screenshot 2025-10-02 at 7 20 28 PM" src="https://github.com/user-attachments/assets/7adab2c2-dac1-4463-96fc-13094da2c379" /> (note that as of now we'd only have at most one script, showing multiple here to demonstrate the different states) <img width="1031" height="524" alt="Screenshot 2025-10-02 at 7 22 01 PM" src="https://github.com/user-attachments/assets/bedaa840-d7ef-4b6f-8daf-6ac3b447594f" /> <img width="1222" height="760" alt="image" src="https://github.com/user-attachments/assets/42cf82d5-53e0-4c4d-b60e-9ac2cc86af68" /> --------- Co-authored-by: Ian Littman <iansltx@gmail.com> |
||
|---|---|---|
| .. | ||
| handlers | ||
| default-handlers.ts | ||
| jest.config.ts | ||
| mock-server.ts | ||
| README.md | ||
| stubs.ts | ||
| test-setup.ts | ||
| test-utils.tsx | ||
Fleet UI tests
The test directory contains the jest configuration, test setup, request handlers, mock server definition, testing utilities, and entity stubs (deprecated and will be replaced by mocks in frontend/__mocks__) for use in test files throughout the application. The test files for components and app functions are located in the same directory as the files they test.
Table of contents
- Jest configuration
- Test setup
- Request handlers and their setup
- Testing utilities
- Entity stubs (deprecated)
- Related links
Jest configuration
This is where the jest configuration is located. Refer to Jest's official documentation.
Test setup
This file configures the testing environment for every test file.
Request handlers and their setup
Default handlers and custom handlers are both defined within the handlers directory and return mocked data. The handlers directory will naturally grow with more default and custom handlers required for more tests. We use mock service worker to define all request handlers.
Default handlers and custom handlers differ in their setup. Default handlers are setup in mock-server.ts. The mock server will serve the default handlers outlined in default-handlers.ts. Custom handlers must be setup inline within a component's test suite (frontend/**/ComponentName.tests.tsx). For example, we would setup the custom handler activityHandler9Activities inline using mockServer.use(activityHandler9Activities);.
Testing utilities
We use various utility functions to write our tests.
Testing stubs Deprecated
Testing stubs are still being used in a handful of old tests. We are no longer following this pattern of adding data to testing stubs. Rather, we are building stubs as mocks located in the frontend/__mocks__ directory.
Related links
Check out how we mock data used for unit and integration tests.
Follow this guide to run tests locally.
Visit the frontend overview of Fleet UI testing for more information on our testing strategy, philosophies, and tools.