Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/t1/tdder/nested-fixture-patternnpx skills add t1/tdder --skill nested-fixture-patterngit clone --depth 1 https://github.com/t1/tdderWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00090 | $0.01959 |
| Opus 5 | $0.00045 | $0.00979 |
| Sonnet 5 | $0.00018 | $0.00392 |
| Haiku 4.5 | $0.00009 | $0.00196 |
Grade A, and why
nested-fixture-pattern scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 224 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Nested Fixture Pattern
A pattern combining JUnit's @Nested classes, @RegisterExtension, and ExtensionContext.Store
to build declarative scenario trees where each nesting level adds a scope with fixture-managed data.
Tests focus on what's specifically relevant to them; expensive setup/teardown happens once per scope;
any subtree runs in isolation.
For background, rationale, and tradeoffs, see the blog post.
When to Use
- Multiple, layered preconditions: 2+ levels of setup that depend on each other, making setup code complex
- Expensive shared setup: servers, databases, provisioned users that shouldn't repeat per test
- Well-understood domain: the scenarios are stable enough that
Given...class names can meaningfully describe each level - Subtree isolation needed: you want to run any subset of the scenario tree independently in the IDE
When Not to Use
- Simple tests with flat preconditions: just use
@BeforeAllor@BeforeEach - Each test method needs different setup: use parameterized tests
- Fast, isolated unit tests: overhead of fixtures and nesting isn't worth it
- Precondition hierarchies still in flux: refactoring fixtures is more expensive than flat setup
Suggesting the Pattern
When you detect layered test setup (2+ levels of dependent @BeforeAll/@BeforeEach, or test classes
with complex shared state), use AskUserQuestion:
- Question: "This test has layered preconditions. Want to apply the nested fixture pattern?"
- Options:
- "Yes, refactor to nested fixtures" — briefly describe what the fixture tree would look like
- "No, keep flat setup" — acknowledge the trade-off (simpler structure, more setup duplication)
The Pattern
Each @Nested class is a Given clause. Each @RegisterExtension static field is a fixture
that sets up when entering that class and tears down when leaving.
class DocumentSharingScenarioTest {
@RegisterExtension static ServerFixture server = new ServerFixture();
@Nested class GivenUserAlice {
@RegisterExtension static UserFixture alice = server.createUser("alice");
@Test void seesEmptyDocumentList() {
then(alice.listDocuments()).isEmpty();
}
@Nested class GivenDocument {
@RegisterExtension static DocumentFixture doc =
alice.createDocument("notes.txt", "hello world");
@Test void isVisibleToAlice() {
then(alice.getDocument(doc.id()))
.hasName("notes.txt")
.hasContent("hello world");
}
@Nested class GivenSharedWithBob {
@RegisterExtension static UserFixture bob = server.createUser("bob");
@RegisterExtension static ShareFixture share =
doc.shareTo(bob, Permission.READ);
@Test void bobCanRead() {
then(bob.getDocument(doc.id()))
.hasContent("hello world");
}
@Test void bobCannotWrite() {
assertThatThrownBy(() ->
bob.updateDocument(doc.id(), "modified"))
.isInstanceOf(ForbiddenException.class);
}
}
}
}
}
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 224 lines · 90 tokens per session scan A 607b645963fa
nested-fixture-pattern is a skill published in the GitHub repository t1/tdder (14 stars, last pushed 2d ago), licensed Apache-2.0. It adds 90 tokens to every session and 1,959 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
java-clean-tests
Enforces test quality in Java with JUnit 5 and AssertJ — one concept per test, boundary coverage, fast isolated tests, parameterised cases, and no disabled tests without a reason. Use when writing or reviewing Java tests, and when the user mentions JUnit, AssertJ, Mockito, Testcontainers, @ParameterizedTest…
test-quality
Write high-quality JUnit 5 tests with AssertJ assertions. Use when user says "add tests", "write tests", "improve test coverage", or when reviewing/creating test classes for Java code.
eclipse-test
Run JUnit tests in Eclipse projects — all tests, by package, by class, or individual test methods. Also build Maven projects.
junit-5-skill
Generates production-grade JUnit 5 unit and integration tests in Java. Covers assertions, parameterized tests, lifecycle hooks, mocking with Mockito, and nested tests. Use when user mentions "JUnit", "JUnit 5", "@Test", "assertEquals", "Assertions", "Java unit test". Triggers on: "JUnit", "@Test", "assertEquals"…
generate-tests
Use when the user asks to generate, create, or write unit tests for code. Analyzes the target code, produces a structured test case list for review, then generates test code. Supports Java (JUnit 5, Mockito, AssertJ).
java-conventions
Java code conventions covering Java 17+ records and sealed classes, formatting/static analysis, Maven/Gradle, JUnit 5, exception handling, constructor injection, streams, and security. Load when writing or reviewing Java code.