fleet/frontend/test
jacobshandling 5d9026b7e5
UI - GitOps Mode: Core abstractions, first batch of applications (#26401)
## For #26229 – Part 1


![ezgif-6bbe6d60c12ed4](https://github.com/user-attachments/assets/37a04b64-abd7-4605-b4ac-9542836ff562)

- This PR contains the core abstractions, routes, API updates, and types
for GitOps mode in the UI. Since this work will touch essentially every
part of the Fleet UI, it is ripe for merge conflicts. To mitigate such
conflicts, I'll be merging this work in a number of iterative PRs. ~To
effectively gate any of this work from showing until it is all merged to
`main`, [this commit](feedbb2d4c) hides
the settings section that allows enabling/disabling this setting,
effectively feature flagging the entire thing. In the last of these
iterative PRs, that commit will be reverted to engage the entire
feature. For testing purposes, reviewers can `git revert
feedbb2d4c25ec2e304e1f18d409cee62f6752ed` locally~ The new settings
section for this feature is feature flagged until all PRs are merged -
to show the setting section while testing, run `ALLOW_GITOPS_MODE=true
NODE_ENV=development yarn run webpack --progress --watch` in place of
`make generate-dev`

- Changes file will be added and feature flag removed in the last PR

- [x] Settings page with routing, form, API integration (hidden until
last PR)
- [x] Activities
- [x] Navbar indicator
- Apply GOM conditional UI to:
    - [x] Manage enroll secret modal: .5
    -  Controls >
        - [x] Scripts:
        - Setup experience > 
            - [x] Install software > Select software modal
        - [x] OS Settings >
            - [x] Custom settings
            - [x] Disk encryption
        - [x] OS Updates
 
2/18/25, added to this PR:

   - [x] Controls > Setup experience > Run script
   - [x] Software >
        - [x] Manage automations modal
        - [x] Add software >
            - [x] App Store (VPP)
            - [x] Custom package
   - [x] Queries
        - [x] Manage
        - [x] Automations modal
        - [x] New
        - [x] Edit
   - [x] Policies
     - [x] Manage
     - [x] New
     - [x] Edit
     -  Manage automations
       - [x] Calendar events


- [x] Manual QA for all new/changed functionality

---------

Co-authored-by: Jacob Shandling <jacob@fleetdm.com>
2025-02-20 08:41:07 -08:00
..
handlers Use get label hosts endpoint on Edit Label page (#25833) 2025-01-31 09:56:43 -06:00
default-handlers.ts UI code cleanup and tests for self service feature (#19487) 2024-06-11 12:56:50 +01:00
jest.config.ts UI - GitOps Mode: Core abstractions, first batch of applications (#26401) 2025-02-20 08:41:07 -08:00
mock-server.ts Frontend Integration Tests: Create activity integration tests, reorganized mock server calls (#8620) 2022-11-15 13:29:12 +00:00
README.md Frontend testing documentation (#8936) 2022-12-14 13:56:56 -05:00
stubs.ts Frontend refactor: To typescript, remove unused testing stubs, functi… (#20306) 2024-07-24 12:08:38 -04:00
test-setup.ts update msw (mock service worker) package to 2.5.1 (#23480) 2024-11-05 10:13:30 -06:00
test-utils.tsx feat: enable multiple ABM and VPP tokens (#21693) 2024-08-29 18:51:46 -04:00

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

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.

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.