mirror of https://github.com/Significant-Gravitas/AutoGPT.git synced 2026-04-08 03:00:28 -04:00

Files

Ubbe a11199aa67 dx(frontend): set up React integration testing with Vitest + RTL + MSW (#12667 )

## Summary
- Establish React integration tests (Vitest + RTL + MSW) as the primary
frontend testing strategy (~90% of tests)
- Update all contributor documentation (TESTING.md, CONTRIBUTING.md,
AGENTS.md) to reflect the integration-first convention
- Add `NuqsTestingAdapter` and `TooltipProvider` to the shared test
wrapper so page-level tests work out of the box
- Write 8 integration tests for the library page as a reference example
for the pattern

## Why
We had the testing infrastructure (Vitest, RTL, MSW, Orval-generated
handlers) but no established convention for page-level integration
tests. Most existing tests were for stores or small components. Since
our frontend is client-first, we need a documented, repeatable pattern
for testing full pages with mocked APIs.

## What
- **Docs**: Rewrote `TESTING.md` as a comprehensive guide. Updated
testing sections in `CONTRIBUTING.md`, `frontend/AGENTS.md`,
`platform/AGENTS.md`, and `autogpt_platform/AGENTS.md`
- **Test infra**: Added `NuqsTestingAdapter` (for `nuqs` query state
hooks) and `TooltipProvider` (for Radix tooltips) to `test-utils.tsx`
- **Reference tests**: `library/__tests__/main.test.tsx` with 8 tests
covering agent rendering, tabs, folders, search bar, and Jump Back In

## How
- Convention: tests live in `__tests__/` next to `page.tsx`, named
descriptively (`main.test.tsx`, `search.test.tsx`)
- Pattern: `setupHandlers()` → `render(<Page />)` → `findBy*` assertions
- MSW handlers from
`@/app/api/__generated__/endpoints/{tag}/{tag}.msw.ts` for API mocking
- Custom `render()` from `@/tests/integrations/test-utils` wraps all
required providers

## Test plan
- [x] All 422 unit/integration tests pass (`pnpm test:unit`)
- [x] `pnpm format` clean
- [x] `pnpm lint` clean (no new errors)
- [x] `pnpm types` — pre-existing onboarding type errors only, no new
errors

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: Nicholas Tindle <nicholas.tindle@agpt.co>
Co-authored-by: Reinier van der Leer <pwuts@agpt.co>

2026-04-06 13:17:08 +00:00

3.7 KiB

Raw Blame History

AutoGPT Platform Contribution Guide

This guide provides context for coding agents when updating the autogpt_platform folder.

Directory overview

autogpt_platform/backend – FastAPI based backend service.
autogpt_platform/autogpt_libs – Shared Python libraries.
autogpt_platform/frontend – Next.js + Typescript frontend.
autogpt_platform/docker-compose.yml – development stack.

See docs/content/platform/getting-started.md for setup instructions.

Code style

Format Python code with poetry run format.
Format frontend code using pnpm format.

Frontend guidelines:

See /frontend/CONTRIBUTING.md for complete patterns. Quick reference:

Pages: Create in src/app/(platform)/feature-name/page.tsx
- Add usePageName.ts hook for logic
- Put sub-components in local components/ folder
Components: Structure as ComponentName/ComponentName.tsx + useComponentName.ts + helpers.ts
- Use design system components from src/components/ (atoms, molecules, organisms)
- Never use src/components/__legacy__/*
Data fetching: Use generated API hooks from @/app/api/__generated__/endpoints/
- Regenerate with pnpm generate:api
- Pattern: use{Method}{Version}{OperationName}
Styling: Tailwind CSS only, use design tokens, Phosphor Icons only
Testing: Integration tests (Vitest + RTL + MSW) are the default (~90%, page-level). Playwright for E2E critical flows. Storybook for design system components. See autogpt_platform/frontend/TESTING.md
Code conventions: Function declarations (not arrow functions) for components/handlers

Component props should be interface Props { ... } (not exported) unless the interface needs to be used outside the component
Separate render logic from business logic (component.tsx + useComponent.ts + helpers.ts)
Colocate state when possible and avoid creating large components, use sub-components ( local /components folder next to the parent component ) when sensible
Avoid large hooks, abstract logic into helpers.ts files when sensible
Use function declarations for components, arrow functions only for callbacks
No barrel files or index.ts re-exports
Avoid comments at all times unless the code is very complex
Do not use useCallback or useMemo unless asked to optimise a given function
Do not type hook returns, let Typescript infer as much as possible
Never type with any, if not types available use unknown

Testing

Backend: poetry run test (runs pytest with a docker based postgres + prisma).
Frontend integration tests: pnpm test:unit (Vitest + RTL + MSW, primary testing approach).
Frontend E2E tests: pnpm test or pnpm test-ui for Playwright tests.
See autogpt_platform/frontend/TESTING.md for the full testing strategy.

Always run the relevant linters and tests before committing. Use conventional commit messages for all commits (e.g. feat(backend): add API). Types: - feat - fix - refactor - ci - dx (developer experience) Scopes: - platform - platform/library - platform/marketplace - backend - backend/executor - frontend - frontend/library - frontend/marketplace - blocks

Pull requests

Use the template in .github/PULL_REQUEST_TEMPLATE.md.
Rely on the pre-commit checks for linting and formatting
Fill out the Changes section and the checklist.
Use conventional commit titles with a scope (e.g. feat(frontend): add feature).
Keep out-of-scope changes under 20% of the PR.
Ensure PR descriptions are complete.
For changes touching data/*.py, validate user ID checks or explain why not needed.
If adding protected frontend routes, update frontend/lib/supabase/middleware.ts.
Use the linear ticket branch structure if given codex/open-1668-resume-dropped-runs

3.7 KiB Raw Blame History Unescape Escape