## PR 2/2 for #32037 - Implements update for the Linux setup experience from the end-user's point of view (the "My device" page). - Works in concert with the new endpoints implemented in https://github.com/fleetdm/fleet/pull/32493 - My device page calls a new endpoint to get in-progress setup experience software installations. If there are any, the page is replaced with a "Setting up your device" page - The UI polls this endpoint until all such installations are either successful or failed (including canceled) - Setting up your device page includes a table displaying the name and status of each software installation - Once all installations are finished (succeed/fail), renders the regular My device page - Add a handler for the new API call for relevant tests  ## Testing Can use [this branch with fake data](https://github.com/fleetdm/fleet/tree/32037-end-user-fake-data) to help test this PR - [x] Changes file added for user-visible changes in `changes/` - [x] Added/updated automated tests - additional tests coming in follow-up - [x] QA'd all new/changed functionality manually --------- Co-authored-by: Jacob Shandling <jacob@fleetdm.com> |
||
|---|---|---|
| .. | ||
| activityMock.ts | ||
| appleMdm.ts | ||
| axiosError.ts | ||
| certificatesMock.ts | ||
| configMock.ts | ||
| deviceUserMock.ts | ||
| fileMock.js | ||
| hostMock.ts | ||
| idpMock.ts | ||
| labelsMock.ts | ||
| licenseMock.ts | ||
| macAdminsMock.ts | ||
| mdmMock.ts | ||
| operatingSystemsMock.ts | ||
| osqueryTableMock.ts | ||
| policyMock.ts | ||
| queryMock.ts | ||
| queryReportMock.ts | ||
| README.md | ||
| scheduleableQueryMock.ts | ||
| scriptMock.ts | ||
| setupExperienceMock.ts | ||
| softwareMock.ts | ||
| teamMock.ts | ||
| userMock.ts | ||
| vulnerabilitiesMock.ts | ||
Frontend mocks
Each __mocks___/*Mock.ts file contains one or more default mock objects and their corresponding helper function to partially override the default mock creating custom mocks.
Table of contents
- Default mocks usage -Example
- Custom mocks usage -Global handlers vs. inline handlers -Examples
- Related links
Default mocks
Default mocks are simple to work with objects. We limit the default mock to a single object that can be modified with the helper function as needed using overrides.
The default mock object is returned by calling the helper function with no arguments.
Example
A single default activity is defined in __mocks__/activityMock.ts as:
const DEFAULT_ACTIVITY_MOCK: IActivity = {
created_at: "2022-11-03T17:22:14Z",
id: 1,
actor_full_name: "Test",
actor_id: 1,
actor_gravatar: "",
actor_email: "test@example.com",
type: ActivityType.EditedAgentOptions,
};
To return this default object, call its helper function createActivityMock() with no arguments.
Custom mocks
Custom mocks are useful when we need a mock object with specific data.
Use the helper function with arguments to override the default mock data with the specific data you need.
Example
createMockActivity({ id: 2, actor_full_name: "Gabe" }) will return modifications to the DEFAULT_ACTIVITY_MOCK to override the id and actor_full_name keys only.
Related links
Check out the frontend test directory for information about our unit and integration testing layers. We use default mocks and custom mocks when mocking server requests.
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.