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 |
||
|---|---|---|
| .github | ||
| .travis | ||
| config | ||
| deploy | ||
| devel | ||
| distribution | ||
| schutzbot | ||
| src | ||
| .eslintrc.yml | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .stylelintrc.json | ||
| .travis.yml | ||
| babel.config.js | ||
| build_deploy.sh | ||
| codecov.yml | ||
| LICENSE | ||
| package-lock.json | ||
| package.json | ||
| pr_check.sh | ||
| README.md | ||
image-builder-frontend
Frontend Development
To develop the frontend you can use a proxy to run image-builder-frontend locally against the chrome and backend at console.redhat.com.
Working against the production environment is preferred, as any work can be released without worrying if a feature from stage has been released yet.
Nodejs and npm version
Make sure you have npm@7 and node 15+ installed. If you need multiple versions of nodejs check out nvm.
Webpack proxy
-
run
npm ci -
run
npm run prod-beta. This command uses a prod-beta env by default. Configure your environment by theenvattribute indev.webpack.config.js. -
Secondly redirect a few
prod.foo.redhat.comto localhost, if this has not been done already.
echo "127.0.0.1 prod.foo.redhat.com" >> /etc/hosts
- open browser at
https://prod.foo.redhat.com:1337/beta/insights/image-builder
Webpack proxy (staging) -- Runs with image-builder's stage deployment
-
run
npm ci -
run
npm run stage-beta. This command uses a stage-beta env by default. Configure your environment by theenvattribute indev.webpack.config.js. -
Secondly redirect a few
stage.foo.redhat.comto localhost, if this has not been done already.
echo "127.0.0.1 stage.foo.redhat.com" >> /etc/hosts
- open browser at
https://stage.foo.redhat.com:1337/beta/insights/image-builder
Insights proxy (deprecated)
-
Clone the insights proxy: https://github.com/RedHatInsights/insights-proxy
-
Setting up the proxy
Choose a runner (podman or docker), and point the SPANDX_CONFIG variable to
profile/local-frontend.jsincluded in image-builder-frontend.sudo insights-proxy/scripts/patch-etc-hosts.sh export RUNNER="podman" export SPANDX_CONFIG=$PATH_TO/image-builder-frontend/profiles/local-frontend.js sudo -E insights-proxy/scripts/run.sh -
Starting up image-builder-frontend
In the image-builder-frontend checkout directory
npm install npm start
The UI should be running on https://prod.foo.redhat.com:1337/beta/insights/image-builder/landing. Note that this requires you to have access to either production or stage (plus VPN and proxy config) of insights.
Backend Development
To develop both the frontend and the backend you can again use the proxy to run both the frontend and backend locally against the chrome at cloud.redhat.com. For instructions see devel/README.md.
Style Guidelines
This project uses eslint's recommended styling guidelines. These rules can be found here: https://eslint.org/docs/rules/
Test Guidelines
Testing is done using React Testing Library. All UI contributions must also include a new test or update an existing test in order to maintain code coverage.
Tests can be run with
npm run test
These tests will also be run in our Travis CI when a PR is opened.