Inconsistent dynamic import of userEvent

userEvent is statically imported at the top of every other test file in this PR (e.g. ExportTypeSelector.test.tsx, HelpLink.test.tsx), but here it is dynamically imported inside the test body. This introduces unnecessary async overhead and is inconsistent with the established pattern. Move the import to the top of the file alongside the other imports.

And add at the top of the file:

import userEvent from "@testing-library/user-event";

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

PolicySelect.onChange two-argument signature is never exercised

The component's onChange prop has the signature (toolName: string, policy: string) => void — it is called as onChange(toolName, v) in the implementation. However, none of the tests verify that onChange is actually invoked with both arguments. This means a refactor that accidentally drops toolName from the call would go undetected. Consider adding a test like:

it("should call onChange with toolName and new policy value when selection changes", async () => {
  const user = userEvent.setup();
  const onChange = vi.fn();
  renderWithProviders(
    <PolicySelect
      value="untrusted"
      toolName="test-tool"
      saving={false}
      onChange={onChange}
    />
  );
  await user.click(screen.getByRole("combobox"));
  await user.click(screen.getByText("trusted"));
  expect(onChange).toHaveBeenCalledWith("test-tool", "trusted");
});

Locale-sensitive toLocaleDateString() used in regex constructor

new RegExp(from.toLocaleDateString()) is fragile in two ways:

1. In some locales (e.g. German "1.1.2024"), the . in the formatted string becomes a wildcard in the resulting regex, so the assertion matches more broadly than intended.
2. If the test is run in a locale that formats the date differently than the CI environment, the regex could silently never fail.

Both issues can be avoided by using a fixed locale:

And create the dates with the same locale in mind, or alternatively use toBeInTheDocument with the exact rendered string.

Tooltip "Learn more" link is inaccessible to mouse users — test doesn't expose this

In HelpLink.tsx, the tooltip container has style={{ pointerEvents: "none" }}. The button's onMouseLeave fires as soon as the cursor moves away from the button (e.g. to reach the "Learn more" link), which immediately sets showTooltip = false and unmounts the tooltip. The link therefore cannot be clicked by a mouse user even though it is rendered.

The test only asserts the link text appears immediately after hover — it doesn't attempt to move focus to the link and click it — so the inaccessibility is not caught. Consider adding an interaction test, and fixing the component to keep the tooltip visible while the mouse is over it (e.g. include both the button and the tooltip in the onMouseLeave boundary).

aria-expanded does not verify disabled state

aria-expanded="false" simply means the dropdown is currently closed — which is also true for a non-disabled select that hasn't been opened. This assertion passes regardless of the saving prop and therefore doesn't contribute to verifying the disabled state. A non-disabled select would also satisfy this assertion, so it will not catch a regression where disabled={saving} is accidentally removed.

The correct ARIA attribute for disabled state on an Ant Design combobox is aria-disabled="true". Replace the first assertion:

Duplicate test cases reduce suite value

"should render" (lines 13–20) and "should display TPM label for tpm type" (lines 22–29) are identical: both render <RateLimitTypeFormItem type="tpm" name="tpm_type" /> and assert screen.getByText(/TPM Rate Limit Type/). If the first test passes, the second must too, and vice versa — one of them provides no additional coverage. Consider merging them into a single meaningful test, or converting "should render" into a smoke test that verifies the component mounts without throwing.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

policyStyle tests rely on fragile index-based assertions

Both assertions reference positional indices into INPUT_POLICY_OPTIONS:

expect(policyStyle("trusted")).toEqual(INPUT_POLICY_OPTIONS[1]);
expect(policyStyle("blocked")).toEqual(INPUT_POLICY_OPTIONS[2]);

If the order of INPUT_POLICY_OPTIONS is ever changed (e.g., to alphabetical), policyStyle("trusted") will still return the object whose value === "trusted", but INPUT_POLICY_OPTIONS[1] may now be a different object — causing a spurious test failure even though the function behaves correctly. Assert on the return value's identity property instead: