Skills DirectorySkills Directory
SkillsLearnSecurityCategoriesDocsCommunityBlog
Sign InSubmit Skill
Skills Directory

Security-tested agent skills for Claude, coding agents, and AI workflows.

Directory

  • Browse Skills
  • All Skills A–Z
  • Claude Skills
  • Claude Code Skills
  • Agent Skills
  • Categories
  • Submit a Skill

Learn

  • Learn Hub
  • Install Claude Skills
  • Write SKILL.md
  • Skills vs MCP
  • Directories Compared

Security

  • Security
  • Methodology
  • Secure Claude Skills
  • Security Badges

Company

  • About
  • Community
  • Blog
  • API Docs
  • Advertise

2026 Skills Directory. All rights reserved.

Back to skills

Backend Test Fixtures

ASecurity

Shared test fixtures for backend specs — port mock factories, domain builders, and shared IDs in a per-module testing/ folder. Use when a module's *.use-case.spec.ts files repeat the same mock-repository literal, inline entity construction, or hardcoded UUIDs across files.

33 stars
0 votes
0 copies
0 views
Added 9/20/2026
testingbashtestingbackend

Security Analysis

A100/100

Scanned 9/20/2026

Install to Claude Code

$npx -y skills add ayunis-core/ayunis-core --skill backend-test-fixtures --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Backend Test Fixtures?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Backend Test Fixtures
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/ayunis-core-backend-test-fixtures/badge)](https://www.skillsdirectory.com/skills/ayunis-core-backend-test-fixtures)

More formats (shields.io, HTML) on the badges page.

Download Zip
Files
SKILL.md
---
name: backend-test-fixtures
description: Shared test fixtures for backend specs — port mock factories, domain builders, and shared IDs in a per-module testing/ folder. Use when a module's *.use-case.spec.ts files repeat the same mock-repository literal, inline entity construction, or hardcoded UUIDs across files.
---

# Backend Test Fixtures

Most repetition in backend unit specs is **setup**, not assertions: the same
port mock object, the same `new Entity({...})` literals, and the same hardcoded
UUIDs copy-pasted into every `*.spec.ts`. Extract that setup into a per-module
fixtures file so a port-signature change is a one-line edit instead of a
nine-file sweep.

**Extract setup. Keep assertions explicit.** Per-test `expect(...).toEqual(...)`
bodies document the contract — never hide them behind helpers.

## When to use

- A module has ≥3 specs that each re-declare the same `jest.Mocked<XRepository>` literal.
- Specs build the same domain entity inline (`new UserCreditLimit({...})`) repeatedly.
- The same UUID literals (`'1111…'`, `'2222…'`) appear across multiple specs.

**When NOT to use:** a single spec, or a one-off mock used in one place. Don't
build infrastructure for one caller.

## The hard constraint: keep `jest` out of the production build

A fixtures file uses the `jest` global, so it must never reach the production
`tsc` build. `tsconfig.build.json` only excludes `**/*spec.ts`, so the file
**cannot** be named `*.fixtures.ts` at an arbitrary path.

Put it in a `testing/` folder, which is excluded from both the build and
coverage:

- `tsconfig.build.json` → `exclude` includes `"**/testing/**"`
- `package.json` jest `collectCoverageFrom` → includes `"!**/testing/**"`

Both exclusions already exist (added with the credit-limits fixtures). Place new
fixtures under `<module>/application/testing/` and they are covered. Import them
**only** from `*.spec.ts` files.

## The pattern (canonical example)

See `src/iam/credit-limits/application/testing/credit-limit.fixtures.ts` and any
of `src/iam/credit-limits/application/use-cases/*/*.use-case.spec.ts`.

A fixtures file exports three things:

```ts
// 1. Shared identifiers — one source of truth for test IDs.
export const TEST_ORG_ID = '11111111-1111-1111-1111-111111111111' as UUID;
export const TEST_USER_ID = '22222222-2222-2222-2222-222222222222' as UUID;
export const TEST_TEAM_ID = '33333333-3333-3333-3333-333333333333' as UUID;

// 2. Domain builders — sensible defaults, override only what the test asserts.
//    One builder per entity subclass, so there is no union to juggle.
export function aUserCreditLimit(
  overrides: { orgId?: UUID; userId?: UUID; monthlyCredits?: number } = {},
): UserCreditLimit {
  const { orgId = TEST_ORG_ID, userId = TEST_USER_ID, monthlyCredits = 5000 } = overrides;
  return new UserCreditLimit({ orgId, userId, monthlyCredits });
}

// 3. A port mock factory — defaults model the "empty" state. No `as` cast needed:
//    the object literal already satisfies jest.Mocked<T>.
export function createMockCreditLimitRepository(): jest.Mocked<CreditLimitRepository> {
  return {
    save: jest.fn().mockImplementation((limit) => Promise.resolve(limit)),
    findUserLimits: jest.fn().mockResolvedValue([]),
    findByUserId: jest.fn().mockResolvedValue(null),
    // …every port method, with a sensible default…
  };
}
```

In a spec, setup collapses to:

```ts
const orgId = TEST_ORG_ID;
const repository = createMockCreditLimitRepository();
const existing = aUserCreditLimit({ monthlyCredits: 1000 });
repository.findByUserId.mockResolvedValue(existing);   // override per test
```

## Rules

- **Defaults model the empty/happy path.** Mock finders resolve to `null`/`[]`,
  `save` echoes its argument, deletes resolve. Tests override per case.
- **`import type` for type-only imports** (the port is only used in
  `jest.Mocked<T>`), and **no `as jest.Mocked<T>` cast** on the literal — both
  trip ESLint otherwise.
- **One builder per entity subclass** (`aUserCreditLimit` / `aTeamCreditLimit`)
  rather than a single builder that branches on scope.
- Keep the dominant spec style (`Test.createTestingModule`) — fixtures replace
  the *mock setup*, not the testing harness.

## Validate

```bash
pnpm jest src/<module>                                  # specs still green
pnpm exec tsc -p tsconfig.build.json --noEmit                 # testing/ NOT compiled
pnpm exec eslint --max-warnings=0 <changed files>             # mirrors pre-commit
```

Attribution

ayunis-coreayunis-core
View sourceMore from ayunis-core →
SSkills DirectorySkills Directory

Your tool, in front of Claude Code builders.

3 founder slots · $299/mo · GSC-verified traffic · sponsors can never buy grades.

See placements

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

SSkills DirectorySkills Directory

Your tool, in front of Claude Code builders.

3 founder slots · $299/mo · GSC-verified traffic · sponsors can never buy grades.

See placements

Related Skills

Screen Reader Testing

Practical guide to testing web applications with screen readers for comprehensive accessibility validation.

393431 votes

Python Testing

使用pytest、TDD方法、夹具、模拟、参数化和覆盖率要求的Python测试策略。

2456590 votes

Tdd Workflow

在编写新功能、修复错误或重构代码时使用此技能。强制执行测试驱动开发,包含单元测试、集成测试和端到端测试,覆盖率超过80%。

2456590 votes

Springboot Tdd

使用JUnit 5、Mockito、MockMvc、Testcontainers和JaCoCo进行Spring Boot的测试驱动开发。适用于添加功能、修复错误或重构时。

2456590 votes

Eval Harness

克劳德代码会话的正式评估框架,实施评估驱动开发(EDD)原则

2456590 votes
View all in testing →