Playwright tests

.gitignore

@@ -36,3 +36,7 @@ docs/graphql-api/public
 .VSCodeCounter
 *.old.*
 __pycache__/*
+/test-results/
+/playwright-report/
+/blob-report/
+/playwright/.cache/

.vscode/settings.json

@@ -11,6 +11,7 @@
   "editor.formatOnPaste": false, // required
   "editor.formatOnType": false, // required
   "editor.formatOnSave": true,
+  "prettier.configPath": ".prettierrc",
 
   // eslint
   "eslint.workingDirectories": ["./", "./front", "./shared-components", "./statviz"],
@@ -29,5 +30,6 @@
   },
 
   "typescript.tsdk": "node_modules/typescript/lib",
-  "typescript.enablePromptUseWorkspaceTsdk": true
+  "typescript.enablePromptUseWorkspaceTsdk": true,
+  "git.enableCommitSigning": true
 }

back/README.md

@@ -378,7 +378,7 @@ to simulate a god user with ID 8 (for a regular user, set something like `id=1,
 > [!IMPORTANT]
 > To keep the front-end side up-to-date with the GraphQL schema, make sure that the pre-commit command for `*.graphql` files (`id: generate-graphql-ts-types`) is running properly.
 >
-> It should generate both `schema.graphql` (the introspected unified schema) and `graphql-env.d.ts` (the generated types to be ìnferred and consumed in the FE with `gql.tada`) inside `/graphql/generated/`.
+> It should generate `schema.graphql` (the introspected unified schema), `graphql-env.d.ts` (the generated types to be ìnferred and consumed in the FE with `gql.tada`), `types.ts` (base generated types for msw handlers and mocks) and lastly `mocks.ts` (base mocks to make fixtures and use in tests) inside `/graphql/generated/`.
 
 ## Project structure
 

docker-compose.yml

@@ -40,6 +40,7 @@ services:
       NODE_ENV: development
       HUSKY: 0
       FRONT_ENVIRONMENT: ${ENVIRONMENT:-development}
+      FRONT_USE_MSW: ${USE_MSW}
       FRONT_SENTRY_ENVIRONMENT: ${ENVIRONMENT:-development}
       FRONT_SENTRY_FE_DSN: ${SENTRY_FE_DSN:-}
       FRONT_SENTRY_TRACES_SAMPLE_RATE: ${SENTRY_TRACES_SAMPLE_RATE:-}

docs/adr/adr_frontend_tests.md

@@ -0,0 +1,76 @@
+# ADR: Use Playwright for End-to-End and Integration Testing
+
+## Status
+
+Proposed
+
+## Context
+
+The current testing setup for the Boxtribute front-end project uses React Testing Library and Vitest for unit and integration tests. While these tools are effective for testing individual components and their interactions, they do not provide a comprehensive solution for end-to-end (E2E) testing. E2E testing is crucial for ensuring that the application works correctly from the user's perspective, covering the entire workflow from start to finish.
+
+Additionally, we are using Mock Service Worker (MSW) to mock API requests and avoid hitting the real server and database during tests. This allows us to test the application in isolation and ensure consistent test results.
+
+## Decision Drivers
+
+1. **Comprehensive E2E and Integration Testing**: We need a testing framework that can simulate real user interactions and test the application as a whole, as well as handle integration tests with mocked API requests.
+2. **Cross-Browser Testing**: The ability to test the application across different browsers to ensure compatibility.
+3. **Ease of Use**: The testing framework should be easy to set up and use, with good documentation and community support.
+4. **Performance**: The framework should be fast and efficient, minimizing the impact on the development workflow.
+5. **Integration with CI/CD**: The framework should integrate well with our existing CI/CD pipeline.
+
+## Considered Options
+
+1. **React Testing Library + Vitest**
+
+   - Pros:
+     - Well-suited for unit and integration tests.
+     - Good community support and documentation.
+     - Easy to set up and use.
+   - Cons:
+     - Limited to testing individual components and their interactions.
+     - Does not provide comprehensive E2E testing capabilities.
+     - No built-in support for cross-browser testing.
+
+2. **Playwright**
+   - Pros:
+     - Comprehensive E2E and integration testing capabilities.
+     - Supports cross-browser testing (Chromium, Firefox, WebKit).
+     - Easy to set up and use with good documentation.
+     - Fast and efficient, with parallel test execution.
+     - Integrates well with CI/CD pipelines.
+     - Can be used with Mock Service Worker (MSW) to mock API requests.
+   - Cons:
+     - Additional learning curve for developers familiar with React Testing Library and Vitest.
+     - May require more setup for certain advanced use cases.
+
+## Decision
+
+We have decided to adopt Playwright for both E2E and integration testing in the Boxtribute front-end project. Playwright provides comprehensive testing capabilities, supports cross-browser testing, and integrates well with our existing CI/CD pipeline. Additionally, Playwright can be used with Mock Service Worker (MSW) to mock API requests, allowing us to test the application in isolation.
+
+## Consequences
+
+- **Positive**:
+
+  - Improved test coverage with comprehensive E2E and integration tests.
+  - Ability to test the application across different browsers.
+  - Faster and more efficient testing with parallel test execution.
+  - Better integration with our CI/CD pipeline.
+  - Consistent test results by mocking API requests with MSW.
+
+- **Negative**:
+  - Additional learning curve for developers.
+  - Potential need for additional setup for advanced use cases.
+
+## Implementation
+
+1. Set up Playwright in the project by following the [installation guide](https://playwright.dev/docs/intro).
+2. Write E2E and integration tests using Playwright, utilizing MSW to mock API requests.
+3. Integrate Playwright tests into the CI/CD pipeline.
+4. Gradually replace existing E2E and integration tests written with React Testing Library and Vitest with Playwright tests.
+
+## References
+
+- [Playwright Documentation](https://playwright.dev/docs/intro)
+- [React Testing Library Documentation](https://testing-library.com/docs/react-testing-library/intro)
+- [Vitest Documentation](https://vitest.dev/)
+- [Mock Service Worker Documentation](https://mswjs.io/docs/)

example.env

@@ -18,3 +18,5 @@ TEST_AUTH0_MANAGEMENT_API_CLIENT_ID=ZBDcEypTHMwn23ScgeaMqwzMxO5epguH
 TEST_AUTH0_MANAGEMENT_API_CLIENT_SECRET=
 
 ENVIRONMENT=development
+
+USE_MSW=false

front/browser.ts

@@ -0,0 +1,4 @@
+import { setupWorker } from "msw/browser";
+import { handlers } from "../tests/mswHandlers";
+
+export const worker = setupWorker(...handlers);

front/package.json

@@ -35,17 +35,13 @@
     "@storybook/test": "^8.4.7",
     "@types/react-big-calendar": "^1.16.0",
     "@types/react-table": "^7.7.20",
-    "msw": "^2.7.0",
     "mutationobserver-shim": "^0.3.7",
     "storybook": "^8.4.7"
   },
   "scripts": {
     "build": "tsc && vite build",
     "dev": "vite",
     "preview": "vite preview",
-    "test": "TZ=UTC vitest",
-    "test:coverage": "TZ=UTC vitest run --coverage",
-    "upload:test-report": "./node_modules/.bin/codecov",
     "tsc:check": "tsc --noEmit",
     "tsc:precommit": "tsc-files --noEmit",
     "lint": "eslint --ext ts,tsx --report-unused-disable-directives --max-warnings 0 --ignore-path ../.eslintignore",
@@ -58,8 +54,5 @@
     "format:write": "prettier --write --ignore-path ../.eslintignore",
     "storybook": "storybook dev -p 6006",
     "build-storybook": "storybook build"
-  },
-  "msw": {
-    "workerDirectory": "public"
   }
 }