Write Frontend Tests

Analyze the current branch's frontend changes, plan integration tests, and write them.

References

Before writing any tests, read the testing rules and conventions:

• autogpt_platform/frontend/TESTING.md, testing strategy, file locations, examples
• autogpt_platform/frontend/src/tests/AGENTS.md, detailed testing rules, MSW patterns, decision flowchart
• autogpt_platform/frontend/src/tests/integrations/test-utils.tsx, custom render with providers
• autogpt_platform/frontend/src/tests/integrations/vitest.setup.tsx, MSW server setup

Step 1: Identify changed frontend files

BASE_BRANCH="${ARGUMENTS:-dev}"
cd autogpt_platform/frontend

# Get changed frontend files (excluding generated, config, and test files)
git diff "$BASE_BRANCH"...HEAD --name-only -- src/ \
  | grep -v '__generated__' \
  | grep -v '__tests__' \
  | grep -v '\.test\.' \
  | grep -v '\.stories\.' \
  | grep -v '\.spec\.'

Also read the diff to understand what changed:

git diff "$BASE_BRANCH"...HEAD --stat -- src/
git diff "$BASE_BRANCH"...HEAD -- src/ | head -500

Step 2: Categorize changes and find test targets

For each changed file, determine:

1. Is it a page? (page.tsx), these are the primary test targets
2. Is it a hook? (use*.ts), test via the page/component that uses it; avoid direct renderHook() tests unless it is a shared reusable hook with standalone business logic
3. Is it a component? (.tsx in components/), test via the parent page unless it's complex enough to warrant isolation
4. Is it a helper? (helpers.ts, utils.ts), unit test directly if pure logic

Priority order:

1. Pages with new/changed data fetching or user interactions
2. Components with complex internal logic (modals, forms, wizards)
3. Shared hooks with standalone business logic when UI-level coverage is impractical
4. Pure helper functions

Skip: styling-only changes, type-only changes, config changes.