Chore: homepage tests (#6278)

docs/widgets/authoring/getting-started.md

@@ -33,6 +33,32 @@ Once dependencies have been installed you can lint your code with
 pnpm lint
 ```
 
+## Testing
+
+Homepage uses [Vitest](https://vitest.dev/) for unit and component tests.
+
+Run the test suite:
+
+```bash
+pnpm test
+```
+
+Run the test suite with coverage:
+
+```bash
+pnpm test:coverage
+```
+
+### What tests to include
+
+- New or updated widgets should generally include a component test near the widget component (for example `src/widgets/<widget>/component.test.jsx`) that covers realistic behavior: loading/placeholder state, error state, and a representative "happy path" render.
+- If you add or change a widget definition file (`src/widgets/<widget>/widget.js`), add/update its corresponding unit test (`src/widgets/<widget>/widget.test.js`) to cover the config/mapping behavior.
+- If your widget requires a custom proxy (`src/widgets/<widget>/proxy.js`), add a proxy unit test (`src/widgets/<widget>/proxy.test.js`) that validates:
+  - request construction (URL, query params, headers/auth)
+  - response mapping (what the widget consumes)
+  - error pathways (upstream error, unexpected payloads)
+- Avoid placing test files under `src/pages/**` (Next.js treats files there as routes). Page tests should live under `src/__tests__/pages/**`.
+
 ## Code formatting with pre-commit hooks
 
 To ensure a consistent style and formatting across the project source, the project utilizes Git [`pre-commit`](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) hooks to perform some formatting and linting before a commit is allowed.

docs/widgets/authoring/proxies.md

@@ -201,3 +201,18 @@ export default async function customProxyHandler(req, res, map) {
 ```
 
 Proxy handlers are a complex topic and require a good understanding of JavaScript and the Homepage codebase. If you are new to Homepage, we recommend using the built-in proxy handlers.
+
+## Testing proxy handlers
+
+Proxy handlers are a common source of regressions because they deal with authentication, request formatting, and sometimes odd upstream API behavior.
+
+When you add a new proxy handler or custom widget proxy, include tests that focus on behavior:
+
+- **Request construction:** the correct URL/path, query params, headers, and auth (and that secrets are not accidentally logged).
+- **Response mapping:** the payload shape expected by the widget/component (including optional/missing fields).
+- **Error handling:** upstream non-200s, invalid JSON, timeouts, and unexpected payloads should produce a predictable result.
+
+Test locations:
+
+- Shared handlers live in `src/utils/proxy/handlers/*.js` with tests alongside them (for example `src/utils/proxy/handlers/generic.test.js`).
+- Widget-specific proxies live in `src/widgets/<widget>/proxy.js` with tests in `src/widgets/<widget>/proxy.test.js`.