diff --git a/.agents/rules/test-infrastructure.md b/.agents/rules/test-infrastructure.md
index bb4afa73e4e5..fc5710628d3e 100644
--- a/.agents/rules/test-infrastructure.md
+++ b/.agents/rules/test-infrastructure.md
@@ -71,6 +71,12 @@ The rule: **if production modules already wire a component, use them — don't c
 - Add tests to existing test files rather than creating new ones
 - **Do not duplicate test methods that differ only in parameters** — use `[TestCase(...)]` or `[TestCaseSource(...)]` to parameterize a single method
 - Before writing a new test, check if an existing test can be extended with another `[TestCase]` or use `[TestCaseSource]`
+- **When only parts of tests are similar** — extract the shared parts into helper methods or types instead of copy-pasting:
+  - Shared arrange/build steps → a private helper method, an existing builder (`Build.A.Block...`, `Build.A.Transaction...`, `TestItem.*`), or a new builder if the pattern is reused across files
+  - Shared assertions → a helper method like `AssertExpectedState(...)` so each test asserts in one line and the failure message stays meaningful
+  - Shared scenarios spanning multiple test classes → a base fixture, a shared `static` helper class, or a fixture-level `[SetUp]`
+  - Keep each test body focused on what makes the case unique; the helper should not hide behavior that matters for understanding the test
+- Use `[TestCaseSource]` (not `[TestCase]`) when cases need non-constant data, named scenarios, or grow beyond a handful — keep the source method or `IEnumerable<TestCaseData>` next to the test it feeds
 
 ## DotNetty `IByteBuffer` in tests
 
diff --git a/AGENTS.md b/AGENTS.md
index 0da3002c58dc..167c29baf588 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -22,6 +22,10 @@ This guide helps to get started with the Nethermind Ethereum execution client re
   - Use `<param>`, `<returns>`, `<exception>`, and `<typeparam>` for parameter/return/exception/type-parameter specifics rather than stuffing them into `<summary>` or `<remarks>`.
   - For interface implementations and overrides, prefer `<inheritdoc/>` (optionally with `cref=`) to propagate the contract from the base/interface instead of duplicating it. Add `<remarks>` only when the implementation introduces caller-visible behavior beyond the inherited contract.
   - Reserve in-line comments for implementation-specific details that cannot reasonably live on the member header — e.g. why a particular branch is taken, why a value is computed this way at this exact spot, or a local workaround for a bug elsewhere.
+- Avoid code duplication, especially in tests:
+  - When tests differ only by inputs and expected outputs, parameterize a single test with `[TestCase(...)]` or `[TestCaseSource(...)]` rather than copy-pasting the body. Before adding a new test, check whether an existing one can be extended with another `[TestCase]`.
+  - When only _parts_ of tests are similar (shared setup, common assertions, recurring scenarios), factor those parts into helper methods or helper types (e.g. a builder, a shared static helper, a test fixture base). Keep each test body focused on what makes the case unique.
+  - See [`.agents/rules/test-infrastructure.md`](./.agents/rules/test-infrastructure.md) "Test guidelines" for details.
 
 ---