# How to Test Changes in TREK: A Complete Guide to Unit, Integration, and E2E Testing

> Test TREK changes effectively. Learn to run the full test suite or target specific workspaces and files using npm scripts and Vitest filters for efficient development.

- Repository: [Maurice/TREK](https://github.com/mauriceboe/TREK)
- Tags: how-to-guide
- Published: 2026-07-10

---

**Run `npm test` from the repository root to execute the full test suite across the shared, server, and client workspaces, or target specific workspaces and files using workspace-specific npm scripts and Vitest filters.**

TREK is a monorepo containing three distinct workspaces—**shared**, **server**, and **client**—each with dedicated test suites covering unit, integration, WebSocket, and end-to-end scenarios. Whether you are modifying Zod schemas in the shared workspace or updating Redux slices in the client, understanding how to test changes in TREK ensures your code maintains the repository's strict quality standards and 80%+ coverage threshold.

## Running the Full Test Suite

From the repository root, execute the following command to launch tests for all three workspaces in parallel:

```bash
npm test

```

This command is defined in the root [`package.json`](https://github.com/mauriceboe/TREK/blob/main/package.json) and serves as the quickest sanity check before opening a pull request. It runs the complete test matrix across **shared**, **server**, and **client** workspaces simultaneously, including validation for files like [`shared/src/weather/weather.schema.spec.ts`](https://github.com/mauriceboe/TREK/blob/main/shared/src/weather/weather.schema.spec.ts).

## Testing Individual Workspaces

When working within a specific workspace, navigate to that directory and run its isolated test suite to reduce execution time.

For server-side changes, including API controllers and plugin SDK validation:

```bash
cd server && npm test

```

For client-side React components, Redux logic, and offline sync managers:

```bash
cd client && npm test

```

The same pattern applies to the `shared` workspace, which houses Zod schemas and i18n utilities.

## Targeting Specific Test Files and Suites

For rapid iteration during development, run individual test files directly using Vitest instead of the full suite.

Execute a single server unit test for the SSRF guard:

```bash
cd server && npx vitest run tests/unit/utils/ssrfGuard.test.ts

```

This command targets the security utility tests located at [`server/tests/unit/utils/ssrfGuard.test.ts`](https://github.com/mauriceboe/TREK/blob/main/server/tests/unit/utils/ssrfGuard.test.ts).

Filter tests by name within a workspace using the `--` separator:

```bash
cd client && npm run test -- slices/todoSlice.test.ts

```

This executes the Redux state management tests located at [`client/tests/unit/slices/todoSlice.test.ts`](https://github.com/mauriceboe/TREK/blob/main/client/tests/unit/slices/todoSlice.test.ts).

## Specialized Testing Workflows

TREK includes dedicated scripts for coverage analysis, WebSocket validation, and end-to-end integration testing.

### Coverage Reports

Generate coverage reports to verify your changes meet the 80%+ threshold:

```bash
npm run test:cov

```

This produces coverage metrics for the server and client workspaces, highlighting untested code paths introduced by your modifications.

### WebSocket Tests

Validate real-time collaboration features using the WebSocket-specific test suite:

```bash
cd server && npm run test:ws

```

These tests, located under `server/tests/unit/`, validate connection layer behavior and can be found in files such as [`server/tests/unit/connection.test.ts`](https://github.com/mauriceboe/TREK/blob/main/server/tests/unit/connection.test.ts).

### End-to-End Tests

Run the server's e2e suite to exercise the full HTTP API against an in-memory SQLite database:

```bash
cd server && npm run test:e2e

```

The entry point encompasses all files under `server/tests/e2e/`, ensuring API endpoints function correctly in an integrated environment.

## Development and CI Workflow

Maintain code quality during active development and before submission to avoid CI failures.

### Watch Mode

Enable automatic test re-execution on file changes for immediate feedback:

```bash
npm run test:watch

```

Vitest monitors the codebase and re-runs affected tests instantly whenever you save a file.

### Pre-Commit Validation

The CI pipeline enforces linting and formatting standards. Run these locally before committing:

```bash
npm run lint
npm run format:check

```

### Continuous Integration Gate

When you push a branch and open a PR, the GitHub Actions pipeline automatically executes the full test suite, coverage checks, i18n key parity validation, and schema verification. All gates must pass before merging.

## Summary

- **Run `npm test`** from the repository root to execute all workspace test suites in parallel.
- **Target specific workspaces** by navigating to `server/`, `client/`, or `shared/` and running `npm test`.
- **Isolate specific tests** using `npx vitest run <path>` or `npm run test -- <filter>` for rapid feedback during development.
- **Validate real-time features** with `npm run test:ws` and full API integration with `npm run test:e2e`.
- **Monitor coverage** using `npm run test:cov` to maintain the 80%+ coverage requirement.
- **Use watch mode** (`npm run test:watch`) for continuous testing during refactoring.
- **Always run linting and formatting checks** before committing to ensure CI compliance.

## Frequently Asked Questions

### How do I run only the server tests in TREK?

Navigate to the server workspace and execute `npm test`. This isolates the server-side unit tests, including those for controllers like [`server/tests/unit/nest/trips.controller.test.ts`](https://github.com/mauriceboe/TREK/blob/main/server/tests/unit/nest/trips.controller.test.ts), without running the client or shared workspace suites.

### What testing framework does TREK use?

TREK uses **Vitest** as its primary test runner across all workspaces. The repository leverages Vitest's native filtering capabilities, watch mode, and coverage reporting to manage tests efficiently within the monorepo structure.

### How do I test WebSocket functionality specifically?

Run `npm run test:ws` from the `server` directory. This command executes the WebSocket-specific test suite located in `server/tests/unit/`, validating real-time collaboration features and connection management logic.

### Where are the end-to-end tests located in TREK?

The e2e tests reside in `server/tests/e2e/` and can be executed with `npm run test:e2e` from the server workspace. These tests spin up an in-memory SQLite database and exercise the complete HTTP API surface, ensuring full-stack integration correctness.