This commit makes the `msw` server globally available to all test files.
Given that the majority of our test files will ultimately make calls to
APIs using RTK Query (calls are made in both the table and the wizard),
making these globally available in jest.setup.js is reasonable.
This disables the global filter on the top of the page. So later when an option to filter images by name is added,
there won't be multiple filters which could lead to confusion.
We are migrating towards using RTK Query for API calls, and using `msw`
to mock APIs in our tests.
RTK Query's `fetchBaseQuery` requires the use of `fetch` and `Request`.
`fetch()` was added to Node in v18, and the ability to use it in
Jest tests was added to Jest in v28. However, it still cannot be used
with a `jsdom` test environment.
Therefore, it is necessary to add a polyfill. There are several
libraries available for this but many others in this situation have had
success using `whatwg-fetch` and so it was selected somewhat
arbitrarily.
It is also important that `whatwg-fetch` is imported before
`fetchBaseQuery` (otherwise, a nuisance console warning will be issued).
To ensure this happens, it is imported in a Jest setup file.
This commit adds the necessarily handler, resolver, and server to use
MSW for mocking the /provisioning/v1/sources endpoint.
The server can be used in tests like so:
```javascript
// src/setupTests.js
import { server } from './mocks/server.js'
// Establish API mocking before all tests.
beforeAll(() => server.listen())
// Reset any request handlers that we may add during the tests,
// so they don't affect other tests.
afterEach(() => server.resetHandlers())
// Clean up after the tests are finished.
afterAll(() => server.close())
```
As we begin migrating to RTK Query for API calls, we will need a means
of mocking API endpoints for testing that works well with RTKQ. Mock
Service Worker is an API mocking library that uses the Service Worker
API to intercept actual requests and is recommended for use with RTKQ.
https://mswjs.io/docs/
Some additional justification from the creator of RKT Query that
explains why we would not want to simply continue mocking our API
endpoints using Jest:
```
I wouldn't use jest mocking. I would mock the API.
The reason for this being is that your mocks will assume certain return
values from the RTKQ hook - and if your assumptions are wrong, you might
have a nice green running test, but in reality your app will still fail.
An example of this would be using skip and not checking for
isUninitialized - since that case will not come up if you are not using
skip and you might just assume that you will only ever see isLoading,
isSuccess and isError cases in your component. It's a perfectly valid
assumption in many cases, but not always true. Mocking RTKQ would hide
the resulting bug behind green tests.
Instead, I would recommend using something like mock service worker to
just mock your api endpoints and let RTKQ do it's work. That is how we
are testing RTKQ ourselved in our own tests - you are welcome to take a
ook there: RTKQ tests.
```
https://stackoverflow.com/a/70313785
Require const declarations for variables that are never reassigned after
being declared. If a variable is never reassigned, using the const
declaration is better. const declaration tells readers, “this variable
is never reassigned,” reducing cognitive load and improving
maintainability.
Due to merging the openshift and chrome plugin systems there's
additional requirements on the format of the module name.
Camelcase is the default, so the values can just be removed from the
config.
This commit bumps Jest to 29.4.1. This requires adding two additional
development dependencies.
As of Jest 28 `jest-environment-jsdom` is no longer shipped with Jest by
default, and has therefore been added as a dependency.
`uuid` was also added as a dev dependency. Jest 29 introduced some
compatibility issues with `uuid` that were fixed in `uuid@9`:
https://github.com/uuidjs/uuid/issues/451#issuecomment-1206284480
We import and use `uuid` in our tests, but as it was a dependencies
dependency we did not control which version was installed. Version 8
(what was installed) causes Jest tests to fail like so:
```
SyntaxError: Unexpected token 'export'
> 29 | import { v4 as uuidv4 } from 'uuid';
```
This commit adds the /provisioning/v1/sources endpoint via a new
apiSlice.js which uses RTK Query's createApi method.
RTK Query allows us to query the /provisioning/v1/sources endpoint using an
automatically generated React hook, `useGetSourcesQuery`. The usage is
something like this (from within a React component):
`const { data: sources, isLoading, isSuccess, isError, error } =
useGetSourcesQuery()`.
This will make it much easier for us to manage data caching and just as
importantly manage loading and error states properly.
Future PRs will migrate data fetching in the other slices (clones, composes,
repositories) to the apiSlice.
For more info on RTK Query, see:
https://redux.js.org/tutorials/essentials/part-7-rtk-query-basics
Fixes#909. Fixes#918.
This updates the order of the releases on the Image output step to sort from newest to oldest. The RELEASES Object was converted to Map which remembers insertion order.
The color of the `Show options for further development of RHEL` option in the Release dropdown select was also changed to blue.
Fixes#911. Fixes#912.
This updates the File system step. The changes are:
- changed the toggle group for selecting the mode of partitioning to radio select and updated information for each radio button as mentioned in #911
- added information to the "automatic" option of the file system configuration as mentioned in #912
- updated information for the "manual" option of the configuration as mentioned in mocks
Moving to @redhat-cloud-services/frontend-component utilities broke
several tests, this commit fixes those tests.
Additionally, this commit bumps @patternfly/react-core and
@patternfly/react-table to versions 4.267.6 and 4.112.6, respectively.
Fixes#899. The status of images (parent images and clones) in the
clones table was displayed incorrectly - the 'highest priority'
(e.g. failure > success) was displayed for all images.
This was due to a bug in a conditional in the ImageBuildStatus
component. In the main images table, rows for AWS images should display
the highest priority status of *all* images. A single failed clone
should cause the status of the row in the main images table to be
failure, even if the parent compose status is successful.
This logic was incorrectly being applied to *all* statuses. This commit
fixes this - from now on, this logic is only used for rows in the main
images table.
