Atlas / Skills / cloudai-x / Designing Tests

Designing TestsSAFE

skills/cloudai-x/designing-tests

Universal Claude Code workflow plugin with agents, skills, hooks, and commands

Verdict
SAFE
Grade
B
Trust score
89 /100
Version
—
Hosts
—
License
MIT
Stars
1,418
01

Overview

Universal Claude Code workflow plugin with agents, skills, hooks, and commands

Read from source at commit e93daf1e69daOBSERVED · 2026-10-08
02

What it tells the agent

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: designing-tests
description: Designs and implements testing strategies for any codebase. Use when adding tests, improving coverage, setting up testing infrastructure, debugging test failures, or when asked about unit tests, integration tests, or E2E testing.
---

# Designing Tests

### When to Load

- **Trigger**: Adding tests, test strategy planning, improving coverage, setting up testing infrastructure
- **Skip**: Non-test code changes where testing is not part of the task

## Test Implementation Workflow

Copy this checklist and track progress:

```
Test Implementation Progress:
- [ ] Step 1: Identify what to test
- [ ] Step 2: Select appropriate test type
- [ ] Step 3: Write tests following templates
- [ ] Step 4: Run tests and verify passing
- [ ] Step 5: Check coverage meets targets
- [ ] Step 6: Fix any failing tests
```

## Testing Pyramid

Apply the testing pyramid for balanced coverage:

```
        /\
       /  \     E2E Tests (10%)
      /----\    - Critical user journeys
     /      \   - Slow but comprehensive
    /--------\  Integration Tests (20%)
   /          \ - Component interactions
  /------------\ - API contracts
 /              \ Unit Tests (70%)
/________________\ - Fast, isolated
                   - Business logic focus
```

## Framework Selection

### JavaScript/TypeScript

| Type        | Recommended     | Alternative         |
| ----------- | --------------- | ------------------- |
| Unit        | Vitest          | Jest                |
| Integration | Vitest + MSW    | Jest + SuperTest    |
| E2E         | Playwright      | Cypress             |
| Component   | Testing Library | Vitest Browser Mode |

### Python

| Type        | Recommended                 | Alternative       |
| ----------- | --------------------------- | ----------------- |
| Unit        | pytest                      | unittest          |
| Integration | pytest + httpx              | pytest + requests |
| E2E         | Playwright                  | Selenium          |
| API         | pytest + FastAPI TestClient | -                 |

### Go

| Type        | Recommended        |
| ----------- | ------------------ |
| Unit        | testing + testify  |
| Integration | testing + httptest |
| E2E         | testing + chromedp |

## Test Structure Templates

### Unit Test

```javascript
describe("[Unit] ComponentName", () => {
  describe("methodName", () => {
    it("should [expected behavior] when [condition]", () => {
      // Arrange
      const input = createTestInput();

      // Act
      const result = methodName(input);

      // Assert
      expect(result).toEqual(expectedOutput);
    });

    it("should throw error when [invalid condition]", () => {
      expect(() => methodName(invalidInput)).toThrow(ExpectedError);
    });
  });
});
```

### Integration Test

```javascript
describe("[Integration] API /users", () => {
  beforeAll(async () => {
    await setupTestDatabase();
  });

  afterAll(async () => {
    await teardownTestDatabase();
  });

  it("should create user and return 201", async () => {
    const response = await request(app)
      .post("/users")
      .send({ name: "Test", email: "[email protected]" });

    expect(response.status).toBe(201);
    expect(response.body.id).toBeDefined();
  });
});
```

### E2E Test

```javascript
import { test, expect } from "@playwright/test";

test.describe("[E2E] User Registration Flow", () => {
  test("should complete registration successfully", async ({ page }) => {
    await page.goto("/register");

    await page.getByTestId("email").fill("[email protected]");
    await page.getByTestId("password").fill("SecurePass123!");
    await page.getByTestId("submit").click();

    await expect(page.locator(".welcome-message")).toBeVisible();
    await expect(page).toHaveURL("/dashboard");
  });
});
```

## Coverage Strategy

### What to Cover

- ✅ Business logic (100%)
- ✅ Edge cases and error handling (90%+)
- ✅ API contracts (100%)
- ✅ Critical user paths (E2E)
- ⚠️ UI components (snapshot + interaction)
- ❌ Third-party library internals
- ❌ Simple getters/setters

### Coverage Thresholds

Jest config shown; the Vitest equivalent is `test.coverage.thresholds` in vitest.config.

```json
{
  "coverageThreshold": {
    "global": {
      "branches": 80,
      "functions": 80,
      "lines": 80,
      "statements": 80
    },
    "src/core/": {
      "branches": 95,
      "functions": 95
    }
  }
}
```

## Test Data Management

### Factories/Builders

```javascript
// factories/user.js
export const userFactory = (overrides = {}) => ({
  id: faker.string.uuid(),
  name: faker.person.fullName(),
  email: faker.internet.email(),
  createdAt: new Date(),
  ...overrides,
});

// Usage
const admin = userFactory({ role: "admin" });
```

### Fixtures

```javascript
// fixtures/users.json
{
  "validUser": { "name": "Test", "email": "[email protected]" },
  "invalidUser": { "name": "", "email": "invalid" }
}
```

## Mocking Strategy

### When to Mock

- ✅ External APIs and services
- ✅ Database in unit tests
- ✅ Time/Date for determinism
- ✅ Random values
- ❌ Internal modules (usually)
- ❌ The code under test

### Mock Examples

```javascript
// API mocking with MSW
import { http, HttpResponse } from "msw";

export const handlers = [
  http.get("/api/users", () => {
    return HttpResponse.json([{ id: 1, name: "John" }]);
  }),
];

// Time mocking
vi.useFakeTimers();
vi.setSystemTime(new Date("2024-01-01"));
```

## Test Validation Loop

After writing tests, run this validation:

```
Test Validation:
- [ ] All tests pass: `npm test`
- [ ] Coverage meets thresholds: `npm test -- --coverage`
- [ ] No flaky tests (run multiple times)
- [ ] Tests are independent (order doesn't matter)
- [ ] Test names clearly describe behavior
```

If any tests fail, fix them before proceeding. If coverage is below target, add more tests for uncovered code paths.

```bash
# Run tests
npm test

# Run with coverage
npm test -- --coverage

# Run specific test file
npm 
03

Trust audit

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

LayerWhat it checksResult
L0Provenance & inventoryPASS
L1Static analysis of the codeNA
L2Instruction surface (what it tells the agent)PASS
L3Class-specific surfacePASS
L4Behavioural (sandbox)SKIPPED

What the source does

Filesystem
none-observed
Network
none-observed
Shell
none-observed
Dependencies
pinned
Secrets in source
none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.

Audited 2026-10-08 · audit v0.4.1 · source sha e93daf1e69dafull audit observations/trust-audit/skill/cloudai-x__designing-tests.json · Report an issue / request a re-scan
04

Audit history

Every audit this skill has had.

DateSourceVerdictGradeScoreChange
2026-10-08e93daf1e69daSAFEB89first audit
05

Questions

What does the Designing Tests skill do?

Universal Claude Code workflow plugin with agents, skills, hooks, and commands

Is Designing Tests safe to install?

The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.

What can Designing Tests access on my machine?

The audit observed no filesystem, network or shell use at all in its source.

How current is this page?

The grade is for one exact copy of the source (e93daf1e69da), read on 2026-10-08. The repository is watched, and a new audit runs when it changes — this is the first audit.

Advertisement