TaskMeshAI includes a comprehensive unit test suite with 75 tests covering critical business logic, API routes, and utility functions.
- Statements: 65.06%
- Functions: 90.9%
- Lines: 64.58%
- Branches: 55.76%
| Module | Statements | Functions | Status |
|---|---|---|---|
| lib/x402.ts | 87.5% | 100% | ⭐ Excellent |
| lib/supabase.ts | 66.66% | 100% | ✅ Good |
| agent/summarizer.ts | 78.94% | 50% | ✅ Good |
| app/api/tasks/open | 66.66% | 100% | ✅ Good |
| app/api/tasks/[id]/bid | 88.88% | 100% | ⭐ Excellent |
| app/api/tasks/[id]/complete | 88.88% | 100% | ⭐ Excellent |
| app/api/tasks/[id]/bids | 56.75% | 100% | ✅ Good |
| app/api/tasks/[id]/bids/[bidId]/accept | 42.85% | 100% |
pnpm testpnpm test --watchNODE_ENV=test pnpm exec jest --coveragepnpm test lib/__tests__/x402.test.tslib/__tests__/x402.test.ts- Payment configuration and verificationlib/__tests__/supabase.test.ts- Supabase client initialization and queriesagent/__tests__/summarizer.test.ts- Agent task bidding logicapp/__tests__/api.test.ts- API route handlers
x402.test.ts - 25 tests
getFacilitator()- Credential-based facilitator selectiongeneratePaymentConfig()- Payment configuration generation with various inputsverifyPayment()- Transaction hash validation- Edge cases: empty titles, long strings, decimal amounts, null values
supabase.test.ts - 16 tests
- Client initialization
- Query builder methods (select, insert, update, delete)
- Filter operations (eq, neq)
- Ordering and limiting
- Single row queries
- Chain operations
summarizer.test.ts - 9 tests
- Task fetching from API
- Payment invoice handling (402 status)
- Bid submission
- Task completion scheduling
- Wallet inclusion in requests
- Error handling
api.test.ts - 25 tests organized by endpoint:
GET /api/tasks/open (3 tests)
- Returns valid JSON response
- Returns array or error object
- Handles database errors
POST /api/tasks/[id]/bids (8 tests)
- Accepts valid bids
- Rejects missing fields
- Validates wallet address
- Tests various bid amounts (1, 50, 100, 1000, 10000)
- Returns JSON response
GET /api/tasks/[id]/bids (3 tests)
- Returns bids for task
- Returns array response
- Includes proper headers
POST /api/tasks/[id]/bids/[bidId]/accept (11 tests)
- Validates creator_wallet requirement
- Accepts valid requests
- Handles different bid/task ID formats
- Case-insensitive wallet comparison
- JSON parsing errors
- Null/empty wallet handling
- Long wallet addresses
POST /api/tasks/[id]/bid (2 tests)
- Assigns agent to task
- Returns JSON response
POST /api/tasks/[id]/complete (2 tests)
- Completes task
- Returns JSON response
Error Scenarios (4 tests)
- Invalid JSON in request
- Numeric task IDs
- UUID task IDs
- HTTP status code validation
{
setupFilesAfterEnv: ['<rootDir>/jest.setup.js'],
testEnvironment: 'node',
moduleNameMapper: { '^@/(.*)$': '<rootDir>/$1' },
collectCoverageFrom: [
'agent/**/*.ts',
'app/api/**/*.ts',
'lib/**/*.ts',
],
coverageThreshold: {
global: {
branches: 50,
functions: 60,
lines: 60,
statements: 60,
},
},
}- React components (
components/) - Database migrations (
database/) - Page layouts (
app/layout.tsx,app/page.tsx) - CSS files (
app/global.css) - Static assets (
public/)
- @supabase/supabase-js - Mocked with chainable query builder
- @coinbase/x402 - Mocked facilitator configuration
- fetch API - Mocked for agent tests
NEXT_PUBLIC_SUPABASE_URL=https://test.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=test-anon-key
NEXT_PUBLIC_TREASURY_WALLET=0x0000000000000000000000000000000000000000
CDP_API_KEY_ID=test-key-id
CDP_API_KEY_SECRET=test-key-secret
Complex routes with multiple database operations (like accept/route.ts) have lower statement coverage because:
- Mock Supabase clients return immediately without executing route logic
- Business logic that depends on database responses isn't fully covered
- Recommended: Use integration tests for complete coverage of transaction-like operations
- Integration Tests - Test with real/test Supabase database
- Extract Logic - Move business logic to separate, testable functions
- Accept Limitation - Unit tests excel at input/output validation, not database logic
import { describe, it, expect, beforeEach } from '@jest/globals';
describe('Module Name', () => {
beforeEach(() => {
jest.clearAllMocks();
});
it('should do something', () => {
// Arrange
const input = { /* ... */ };
// Act
const result = functionUnderTest(input);
// Assert
expect(result).toEqual({ /* ... */ });
});
});- Arrange-Act-Assert - Organize test code clearly
- Single Responsibility - One assertion per test concept
- Descriptive Names - Use "should..." naming convention
- Mock External Dependencies - Isolate code under test
- Test Edge Cases - Empty values, null, negative numbers, etc.
Tests should be run in CI/CD pipeline:
# Pre-commit hook
pnpm test
# Pre-push hook
NODE_ENV=test pnpm exec jest --coverage- New features requiring business logic coverage
- Bug fixes that should prevent regression
- API route changes or new endpoints
- Utility function modifications
pnpm test -- -u# Debug specific test
node --inspect-brk node_modules/.bin/jest --runInBand lib/__tests__/x402.test.tsCurrent test suite:
- Time: ~0.4 seconds
- Memory: Minimal (~50MB)
- Parallel Execution: All tests run in parallel