dust-test
Guides the creation of focused, maintainable tests for Dust codebases.
Install
mkdir -p .claude/skills/dust-test && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/2372" && unzip -o skill.zip -d .claude/skills/dust-test && rm skill.zipInstalls to .claude/skills/dust-test
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Step-by-step guide for writing focused, practical tests for Dust codebases following the 80/20 principle.Key capabilities
- →Identify core functionality and critical edge cases
- →Use test factories for efficient data setup
- →Mock external services while using real database connections
- →Test behavior rather than implementation details
- →Execute tests using npm test with file path arguments
How it works
It applies the 80/20 principle to identify the most valuable test paths, utilizes factories for data setup, and mandates minimal mocking to focus on behavior.
Inputs & outputs
When to use dust-test
- →Writing unit tests for Dust services
- →Refactoring test suites
- →Setting up test factories
About this skill
Creating automated tests for Dust codebases
Write focused, practical tests for the current file following the 80/20 principle.
Instructions
When writing tests for a file:
- Identify the core functionality: Focus on the most important paths and edge cases that provide 80% of the value
- Keep it simple: Write straightforward tests that are easy to understand and maintain
- Minimal mocking:
- DO NOT mock the database
- Only mock external services (APIs, third-party services)
- Prefer real implementations when possible
- Use factories: Leverage test factories to set up data efficiently
- Focus on behavior: Test what the code does, not how it does it
For Front and Front-api (TypeScript)
Setup
- Import factories from
front/tests/utils/factories - Import utilities from
front/tests/utils/utils - Use the test database (no mocking)
Structure
import {describe, it, expect} from "vitest";
import {makeTestWorkspace, makeTestUser} from "tests/utils/factories";
describe ("ComponentName or FunctionName", () => {
it ("should handle the main happy path", async () => {
// Arrange: Set up using factories
const {workspace} = createResourceTest ()
// Act: Execute the code
const result = await functionUnderTest (workspace);
// Assert: Verify behavior
expect (result).toBeDefined ();
});
it ("should handle the most common edge case", async () => {
// Test the second most important scenario
});
});
What to test (80/20 focus)
- Main success paths
- Most common error conditions
- Critical edge cases (null/undefined, empty arrays, etc.)
- Permission checks (if applicable)
What to skip (diminishing returns)
- Exhaustive parameter combinations
- Unlikely edge cases
- Internal implementation details
- UI component rendering (unless critical)
For Connectors/Core
Follow similar principles:
- Use factories appropriate to the service
- Focus on integration points
- Mock external APIs only (Slack, Notion, GitHub, etc.)
- Test the database interactions directly
Example Pattern
describe ("createConversation", () => {
it ("creates conversation with valid params", async () => {
const {workspace, user} = createResourceTest ()
const conversation = await createConversation ({
workspace,
userId: user.id,
title: "Test"
});
expect (conversation.sId).toBeDefined ();
expect (conversation.title).toBe ("Test");
});
it ("fails without required permissions", async () => {
const {workspace, user} = createResourceTest ()
await expect (
createConversation ({workspace, userId: user.id})
).rejects.toThrow ("Permission denied");
});
});
Execution Steps
- Read the file to understand its purpose and main exports
- Check if a test file already exists (e.g.,
file.test.ts) - Identify the 2-4 most important functions/behaviors to test
- Find or create appropriate factories for test data
- Write concise, focused tests
- Run tests with
npm test -- filetotestto verify they pass
When not to use it
- →When testing UI component rendering details
- →When exhaustive parameter combinations are required
Prerequisites
Limitations
- →Does not support mocking the database
- →Focuses only on the most important 80% of functionality
How it compares
It prioritizes behavior-driven testing with minimal mocking, whereas generic approaches often rely on exhaustive mocking or UI-state verification.
Compared to similar skills
dust-test side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| dust-test (this skill) | 1 | 4mo | No flags | Intermediate |
| epic-forms | 1 | 6mo | No flags | Intermediate |
| code-review | 0 | 3mo | No flags | Intermediate |
| verify | 0 | 1mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by dust-tt
View all by dust-tt →You might also like
epic-forms
epicweb-dev
Guide on forms with Conform and validation with Zod for Epic Stack
code-review
gh0stfrk
Review code changes in this Next.js portfolio/blog for correctness, security, performance, and maintainability
verify
Achiermann
Build, run and drive the flash-cards app locally to verify UI changes end-to-end (mobile + desktop viewports).
nextjs-developer
zenobi-us
Expert Next.js developer mastering Next.js 14+ with App Router and full-stack features. Specializes in server components, server actions, performance optimization, and production deployment with focus on building fast, SEO-friendly applications.
payload
payloadcms
Use when working with Payload CMS projects (payload.config.ts, collections, fields, hooks, access control, Payload API). Use when debugging validation errors, security issues, relationship queries, transactions, or hook behavior.
shadcn-ui-setup
maneeshanif
Install and configure Shadcn/ui component library with Radix UI primitives, Aceternity UI effects, set up components, and manage the component registry. Use when adding Shadcn/ui to a Next.js project or installing specific UI components for Phase 2.