test: Add component tests for VerificationForm

[SamuelStave]

Closes #366

[drips-wave]

@SamuelStave Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[Copilot]

Pull request overview

Adds a new component test suite for VerificationForm to cover basic rendering, validation, submit behavior, and a11y expectations for the verification request flow.

Changes:

• Introduces VerificationForm component tests using Vitest + Testing Library.
• Mocks Soroban verification requests, analytics tracking, and toast notifications to exercise submit flows.
• Adds assertions around validation, loading state, and basic form semantics.

Suppressed comments (4)

dongle/tests/components/VerificationForm.test.tsx:60

• The validation tests only assert that some element with role="alert" exists. Since the form uses a specific Zod error message, these assertions can pass even if the wrong validation error is shown. Prefer asserting the exact error text (e.g., "Project ID or Domain must be at least 3 characters") to make the tests robust and meaningful.

  it("shows validation error for empty project ID", async () => {
    const user = userEvent.setup();
    render(<VerificationForm />);

    const submitButton = screen.getByRole("button", { name: /Submit Request/i });
    await user.click(submitButton);

    await waitFor(() => {
      expect(screen.getByRole("alert")).toBeInTheDocument();
    });
  });

dongle/tests/components/VerificationForm.test.tsx:86

• This test name/assertion suggests the submit button becomes disabled/enabled based on projectId length, but VerificationForm doesn’t disable the button for validation errors (it only validates on submit). As written, expect(submitButton).not.toBeDisabled() will pass even if the validation rules change or the input is invalid. Consider asserting the validation message is absent after submit with a valid value, or asserting the specific side-effect (e.g., requestVerification called) instead.

  it("accepts valid project ID of 3 or more characters", async () => {
    const user = userEvent.setup();
    render(<VerificationForm />);

    const input = screen.getByLabelText(/Project ID or Domain/i);
    await user.type(input, "myproject.com");

    const submitButton = screen.getByRole("button", { name: /Submit Request/i });
    expect(submitButton).not.toBeDisabled();
  });

dongle/tests/components/VerificationForm.test.tsx:174

• This test uses document.querySelector("form"), which queries the global document rather than the render container. To avoid accidental matches and make the test more isolated, prefer using the container from render(...) (e.g., container.querySelector('form')) or a Testing Library query scoped to the rendered output.

  it("has proper form semantics", () => {
    render(<VerificationForm />);

    const form = document.querySelector("form");
    expect(form).toBeInTheDocument();
  });

dongle/tests/components/VerificationForm.test.tsx:29

• PR description says this closes #366, but #366’s acceptance criteria calls out additional fields/behaviors (evidence description, file upload + preview/validation, and “submit disabled until requirements met”). The current VerificationForm and these tests only cover a single projectId field and don’t exercise those flows. Please confirm whether the issue criteria are outdated, or adjust the issue/PR linkage so we’re not closing an issue that still has unmet requirements.

describe("VerificationForm", () => {
  const defaultOnSuccess = vi.fn();

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.