Running Tests
Relevant source files
The following files were used as context for generating this wiki page:This project employs a multi-layered testing strategy to ensure code quality, correctness, and stability. The approach includes unit, integration, and end-to-end (E2E) tests, leveraging frameworks like Jest, React Testing Library, and Playwright. The development workflow encourages writing tests alongside implementation, with a goal of achieving high test coverage.
The testing architecture is designed to validate different parts of the application, from individual functions and components (unit tests) to feature-level business logic (integration tests) and complete user journeys (E2E tests). This comprehensive strategy helps catch regressions and verify functionality before deployment.
Sources: AGENTS.md:31-34
Test Scripts
The project provides several npm scripts defined in package.json to execute different test suites.
| Script | Description |
|---|---|
test | Runs all Jest unit and integration tests. |
test:watch | Runs Jest tests in interactive watch mode. |
test:e2e | Runs all Playwright End-to-End tests. |
test:e2e:ui | Runs Playwright tests in UI mode for interactive debugging. |
test:e2e:debug | Runs Playwright tests in debug mode. |
Sources: package.json:8-12, E2E_TESTING.md:18-32
End-to-End (E2E) Testing
E2E tests are implemented using Playwright to simulate real user interactions and validate critical user flows from start to finish.
Sources: E2E_TESTING.md:5
Setup and Configuration
Playwright is pre-configured in the project. Key settings in playwright.config.ts include a base URL of http://localhost:3000 and a test timeout of 30 seconds. Tests are designed to run against Chromium, Firefox, and WebKit.
Sources: E2E_TESTING.md:46-52
Running E2E Tests
You can run all E2E tests or target specific files and test cases.
- Run all tests:
pnpm test:e2e - Run a specific file:
pnpm exec playwright test e2e/checkout-cod.spec.ts - Run a specific test by name:
pnpm exec playwright test -g "COD: Complete checkout"
Sources: E2E_TESTING.md:18-32
E2E Test Flow Example: COD Checkout
The e2e/checkout-cod.spec.ts file provides a clear example of an E2E test for the Cash on Delivery (COD) checkout flow. The test automates the user journey from adding a product to the cart to successfully placing an order.
The following diagram illustrates the steps in the "COD: Complete checkout and redirect to success page" test case.
This diagram shows the sequence of user actions and assertions performed by Playwright to validate the COD checkout process.
Sources: e2e/checkout-cod.spec.ts:16-77
E2E Test Coverage
The project has defined E2E test coverage for key payment flows.
| Flow | File | Test Cases |
|---|---|---|
| COD | e2e/checkout-cod.spec.ts |
|
| SePay | e2e/checkout-sepay.spec.ts |
|
Sources: E2E_TESTING.md:36-44
Unit and Integration Testing
Unit and integration tests are written with Jest and React Testing Library. They focus on testing individual functions, components, hooks, and services in isolation.
Sources: package.json:65-68, features/orders/services/orders.service.spec.ts, features/addresses/hooks/use-addresses.spec.ts
Service Layer Testing
Service tests validate the business logic that interacts with the backend API. A key pattern is mocking the API client (api-client) to isolate the service from actual network requests.
In features/orders/services/orders.service.spec.ts, the apiGetValidated and apiPostValidated functions from lib/api-client.ts are mocked using jest.mock. This allows tests to provide controlled responses and verify that the service calls the API client with the correct parameters.
The following sequence diagram illustrates how the ordersApi.getAll() method is tested.
This diagram shows the test initiating the call, the service retrieving the user ID from the mocked auth store, and then calling the mocked API client, which returns a predefined successful response.
Sources: features/orders/services/orders.service.spec.ts:11-25, features/orders/services/orders.service.spec.ts:60-74
Hook Testing
Custom React hooks are tested using @testing-library/react's renderHook. This allows for testing the hook's lifecycle and behavior as if it were in a real component. Dependencies, such as service APIs (addressesApi) and state stores (useCartStore), are mocked to ensure the hook's logic is tested in isolation.
For example, features/addresses/hooks/use-addresses.spec.ts tests the useAddresses hook by:
- Mocking
addressesApito control API responses. - Using
renderHookto mount the hook. - Using
waitForto handle asynchronous operations like data fetching. - Using
actto wrap state-updating actions likecreateorremove. - Asserting the hook's return values (e.g.,
addresses,loading,error) and verifying that mocked functions (liketoast.success) were called.
Sources: features/addresses/hooks/use-addresses.spec.ts:1-1277
Schema and Validation Testing
Zod schemas, which are used for form and API response validation, are also unit tested. Tests for schemas ensure that validation rules are correctly defined. For example, features/products/schemas/product-form.schema.spec.ts verifies that the tryOnImage field correctly accepts valid PNG files under a certain size and rejects invalid file types or oversized files.
Sources: features/products/schemas/product-form.schema.spec.ts:1-51
Specialized Test Scripts
The repository contains specialized scripts for specific testing needs. The scripts/test-face-api-models.ts script is designed to verify that the face-api.js models required for the virtual try-on feature can be loaded correctly from the /public/models directory. While the script notes it requires a browser environment to fully execute, it serves as a utility to confirm model availability.
Sources: scripts/test-face-api-models.ts:1-29