-
Notifications
You must be signed in to change notification settings - Fork 44
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
6 changed files
with
214 additions
and
8 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
# CI/CD Documentation | ||
|
||
This pipeline is set up to ensure our code is clean, reliable, and thoroughly tested before it hits the main branch. Here's how it flows: | ||
|
||
<details> | ||
|
||
<summary>CI/CD Flow Diagram</summary> | ||
|
||
![CI CD Flow](./images/ci-cd-flow.png) | ||
|
||
</details> | ||
|
||
### Github Action Workflows | ||
|
||
1. **[Large File Checks](../.github/workflows/checks.yml)**: We check for any oversized files. We don’t want anything over 5MB sneaking into the repository. | ||
|
||
2. **[Code Quality Checks](../.github/workflows/checks.yml)**: Next, we run our code through ESLint and Prettier. This step makes sure everything is properly formatted and free of linting issues. | ||
|
||
3. **[Unit Tests](../.github/workflows/tests.yaml)**: After that, Jest comes into play to run our unit tests. This checks if all the components and functions are behaving as they should be, catching any issues early on. | ||
|
||
4. **[E2E Tests](../.github/workflows/tests.yaml)**: Finally, we dive into the E2E tests with Cypress. We run these tests in both Chrome and Firefox, making sure the app works as expected across different browsers. These tests also use MSW to mock APIs, ensuring our server-side rendering (SSR) flows are tested just right. | ||
|
||
> Once the CI checks are cleared, our code automatically gets deployed using **_AWS Amplify_**. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,74 @@ | ||
# E2E Flow with Cypress and MSW for SSR | ||
|
||
In our end-to-end (E2E) testing, we use Cypress paired with MSW to mock APIs, especially for testing server-side rendering (SSR) flows. Here’s why this combo works so well: | ||
|
||
**_Why Cypress?_** | ||
|
||
Cypress is great for E2E testing because it lets us interact with the app just like a user would. We can simulate clicks, form submissions, and other interactions, then check if everything responds as expected. It's fast, reliable, and integrates smoothly with our development workflow. | ||
|
||
**_Why MSW?_** | ||
|
||
When it comes to SSR, things can get tricky because server-side logic often depends on external APIs. That’s where MSW (_Mock Service Worker_) comes in. By mocking these API calls, MSW allows us to simulate various backend responses directly in our tests. This way, we can test how the app behaves without relying on the actual backend, which can be slow, unpredictable, or difficult to control. | ||
|
||
**_How It Works Together_** | ||
|
||
Cypress handles the user interactions, while MSW ensures that the SSR logic gets the data it expects, regardless of what’s going on with the real backend. This setup gives us confidence that our SSR pages will render correctly and that our app’s UI will behave as intended, even in edge cases. | ||
|
||
### How to Run It? | ||
|
||
To run the application with the mock server enabled, follow these steps: | ||
|
||
1. **Set Up Environment Variables**: Copy the .env.example and set the environment variables. Make sure to set the `APP_ENV="testing"` to use msw. | ||
|
||
2. **Start the Application**: Run the application. | ||
|
||
```bash | ||
npm run build | ||
npm run start | ||
``` | ||
|
||
> The mock server will automatically start if APP_ENV is set to "testing". | ||
|
||
3. **Verify Mock Server Activation**: When the application starts, you should see console logs confirming that the mock server has been started: | ||
|
||
```bash | ||
Starting Mock Server... | ||
Mock Server Started! | ||
``` | ||
|
||
4. **Run E2E Tests**: To run your end-to-end tests, just execute: | ||
|
||
```bash | ||
npm run test:cypress | ||
``` | ||
|
||
### Key Files to Know | ||
|
||
- **Mock Handlers:** `cypress/mocks/handlers.ts` | ||
|
||
This file contains the API mocking logic for SSR. It defines handlers for API routes, simulating requests like fetching sessions, creating sessions, and patching session data. | ||
|
||
- **Mock Data:** `cypress/mocks/mockdata.ts` | ||
|
||
This data simulates user input in forms and is used by the handlers to respond to requests. | ||
|
||
- **Initial Sessions Data:** `cypress/fixtures/initial_sessions.json` | ||
|
||
This file contains the initial data that's mocked as if it were in the database. The mock server uses this data to simulate a real backend. | ||
- **E2E Test Files:** | ||
- `cypress/e2e/quiz.cy.ts`: Tests related to quiz sessions. | ||
- `cypress/e2e/live.cy.ts`: Tests related to live sessions. | ||
- **Support File:** `cypress\support\index.ts` | ||
Custom commands to test flow easily. | ||
- `customInput(name: string, value: string)` | ||
- `customSelect(name: string, option: Option)` | ||
- `customMultiSelect(name: string, options: Option[])` | ||
- `customSwitch(name: string, value: boolean)` | ||
- `customDatePicker(name: string, value: Date)` | ||
- `customCheckbox(name: string, values: any[])` | ||
- `checkDisabled(selector: string[])` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.