Dust dust-test
Step-by-step guide for writing focused, practical tests for Dust codebases following the 80/20 principle.
install
source · Clone the upstream repo
git clone https://github.com/dust-tt/dust
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/dust-tt/dust "$T" && mkdir -p ~/.claude/skills && cp -r "$T/.claude/skills/dust-test" ~/.claude/skills/dust-tt-dust-dust-test && rm -rf "$T"
manifest:
.claude/skills/dust-test/SKILL.mdsource content
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 (TypeScript/Next.js)
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
to verify they passnpm test -- filetotest