From a294d9b385b09e259c7fb0258354d08f2417e0ea Mon Sep 17 00:00:00 2001
From: "Bonaventure C. J. Ugwu"
 <73999585+BonaventureCJ@users.noreply.github.com>
Date: Sat, 13 Jun 2026 17:08:22 +0100
Subject: [PATCH] docs: prefer test.for over test.each (#10588)

---
 docs/guide/learn/writing-tests-with-ai.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/guide/learn/writing-tests-with-ai.md b/docs/guide/learn/writing-tests-with-ai.md
index ae3c59f4e..ad6788bd0 100644
--- a/docs/guide/learn/writing-tests-with-ai.md
+++ b/docs/guide/learn/writing-tests-with-ai.md
@@ -45,7 +45,7 @@ This tells the AI exactly which function to focus on, which scenarios matter, an
 ### Tips for Better Prompts
 
 - Ask for edge cases explicitly. "Include tests for empty inputs, boundary values, and error handling" produces more comprehensive coverage than leaving it to the AI's judgment. Without this nudge, most tools will generate a handful of happy-path tests and stop there.
-- Mention specific Vitest features if you want them used. "Use `toMatchInlineSnapshot` for the error messages" or "use `test.each` for the different currency formats" guides the AI toward the right tools instead of letting it fall back to repetitive copy-paste tests.
+- Mention specific Vitest features if you want them used. "Use `toMatchInlineSnapshot` for the error messages" or "use `test.for` for the different currency formats" guides the AI toward the right tools instead of letting it fall back to repetitive copy-paste tests.
 - If you're testing async code, say so. "The function returns a Promise" or "this calls an external API" helps the AI use `async`/`await` and appropriate matchers like `.resolves` and `.rejects`.
 - Tell the AI what *not* to do. "Test against the real implementation, don't mock any modules" or "don't use snapshot tests" prevents common defaults you don't want. AI tools tend to over-mock, and an explicit constraint prevents that.
 - Describe the test structure you want. "Group tests by method using `describe` blocks" or "use `test.extend` fixtures for the database connection instead of `beforeEach`" saves you from restructuring the output afterwards.
-- 
2.51.2