Playwright tests

.circleci/config.yml

@@ -138,37 +138,47 @@ jobs:
           paths:
             - front/dist
 
+  lint-front:
+    executor: node-executor
+    working_directory: ~/
+    resource_class: medium+
+    steps:
+      - attach_workspace:
+          at: ~/
+      - run:
+          name: Lint and type-check front app
+          command: |
+            pnpm check-types
+
   test-front:
     executor: node-executor
-    working_directory: ~/front
+    parallelism: 4
+    working_directory: ~/
     resource_class: medium+
     steps:
       - attach_workspace:
           at: ~/
       - run:
-          name: Test front app and create reports
+          name: Install Playwright deps
           command: |
-            DEBUG_PRINT_LIMIT=10000 pnpm test:coverage --test-timeout=40000
+            npx playwright install --with-deps chromium
       - run:
-          name: Test shared-components and create reports
+          name: Test front app and create reports
+          environment:
+            FRONT_AUTH0_DOMAIN: boxtribute-dev.eu.auth0.com
+            FRONT_AUTH0_CLIENT_ID: ni9ZdcoIv3HU10kyc4t1qxOMxjVyxcbS
+            FRONT_USE_MSW: true
           command: |
-            DEBUG_PRINT_LIMIT=10000 pnpm -C ../shared-components test:coverage --test-timeout=40000
-      - store_test_results:
-          path: coverage/junit.xml
-      - store_test_results:
-          path: ../shared-components/coverage/junit.xml
-      - store_artifacts:
-          path: coverage
-          destination: front-coverage
-      - store_artifacts:
-          path: ../shared-components/coverage
-          destination: shared-components-coverage
-      - codecov/upload:
-          flags: frontend
-          file: coverage/coverage-final.json
-      - codecov/upload:
-          flags: sharedComponents
-          file: ../shared-components/coverage/coverage-final.json
+            SHARD="$((${CIRCLE_NODE_INDEX}+1))"; ls tests && pnpm test -- --shard=${SHARD}/${CIRCLE_NODE_TOTAL}
+      # TODO: add coverage, report, record video on fail
+      # - store_test_results:
+      #     path: coverage/junit.xml
+      # - store_artifacts:
+      #     path: coverage
+      #     destination: front-coverage
+      # - codecov/upload:
+      #     flags: frontend
+      #     file: coverage/coverage-final.json
       - slack/notify-on-failure:
           only_for_branches: master,production
 
@@ -440,6 +450,10 @@ workflows:
           context: STAGING
           requires:
             - install-node-packages
+      - lint-front:
+          context: STAGING
+          requires:
+            - install-node-packages
       - test-front:
           context: STAGING
           requires:

.eslintrc.cjs

@@ -83,15 +83,5 @@ module.exports = {
         tsx: "never",
       },
     ],
-  },
-  overrides: [
-    {
-      files: [
-        "**/?(__)tests?(__)/**/*.[jt]s?(x)",
-        "**/?(*.)+(spec|test).[jt]s?(x)",
-        "**/mocks/**/*.[jt]s?(x)",
-      ],
-      extends: ["plugin:testing-library/react"],
-    },
-  ],
+  }
 };

.gitignore

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

.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,79 @@
+# ADR: Use Playwright for Application, Integration and Component Testing
+
+Author: [Felipe](https://github.com/fhenrich33)
+
+Reviewed by: [Roanna K](https://github.com/aerinsol)
+
+## Status
+
+Proposed, Implementing
+
+## 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, the tests usually aren't fully 1-1 representative of what the user will experience. E2E and more involved integration testing are crucial for ensuring that the application works correctly from the user's perspective, covering the entire workflow from start to finish.
+
+Additionally, we use Mock Service Worker (MSW) to mock API requests during tests (and sometimes development) to avoid hitting the real development server and database during tests. This allows us to test the application in isolation and ensure consistent and fast test results.
+
+## Decision Drivers
+
+1. **Comprehensive Testing**: We need a testing framework that can simulate real user interactions, test the application as a whole, and 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 for isolated testing.
+   - Cons:
+     - Limited to testing individual components and their interactions.
+     - Does not provide comprehensive application testing capabilities (in comparison to Playwright).
+     - Runs against a mocked DOM structure (jsdom) instead of a real browser, which leads to flakiness and unreliability.
+     - No built-in support for cross-browser testing.
+
+2. **Playwright**
+   - Pros:
+     - Comprehensive application, integration, and component testing capabilities.
+     - Tests against the real DOM, as even in headless mode the tests run inside a real browser.
+     - Supports cross-browser testing (Chromium, Firefox, WebKit).
+     - Easy to set up and use with excellent documentation. The API for test specs is very similar to React Testing Library.
+     - Ability to generate tests by using the app. See https://playwright.dev/docs/codegen-intro.
+     - Can still run isolated component tests. See https://playwright.dev/docs/test-components.
+     - Can run visual diffing. See https://playwright.dev/docs/test-snapshots.
+     - Fast and efficient, with parallel test execution. Might not match React Testing Library speed but gets close while testing in a real environment.
+     - Integrates well with CI/CD pipelines in headless mode.
+   - Cons:
+     - Additional learning curve for advanced use cases.
+     - Extra setup may be required for advanced use cases.
+     - Slightly slower than React Testing Library for sequential test runs (alleviated by parallel runs).
+
+## Decision
+
+We have decided to adopt Playwright for application, integration, and component 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, while faithfully mimicking the real server since the mocks infer the data types from the GraphQL Schema. Vitest will still be used for individual TypeScript functions and modules.
+
+## Consequences
+
+- **Positive**:
+
+  - Improved test coverage with comprehensive application, integration, and component tests.
+  - Ability to test the application across different browsers.
+  - Fast testing with parallel test execution, while being more faithful to how a user will experience the app.
+  - Better integration with our CI/CD pipeline. Less prone to flakiness.
+  - Consistent test results by mocking API requests with MSW based on our GraphQL Schema.
+
+- **Negative**:
+  - Additional learning curve for developers.
+  - Potential need for additional setup for advanced use cases.
+  - Heavier Development and CI/CD setup, as we install real browsers as dependencies.
+
+## 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