Use when writing tests, setting up test frameworks, implementing mocking strategies, or establishing testing best practices (unit, integration, E2E) across any technology stack.
Use when writing tests, setting up test frameworks, implementing mocking strategies, or establishing testing best practices (unit, integration, E2E) across any technology stack.
Real database/API calls (often with test containers)
Medium speed (100ms - 1s per test)
Run on commit/PR
End-to-End Tests (5-10%)
Test complete user flows
Real browser/environment
Slow (seconds to minutes)
Run before deployment
Test Structure: AAA Pattern
// Arrange - Set up test data and conditions
const user = createTestUser({ email: 'test@example.com' });
const service = new UserService(mockDb);
// Act - Execute the code under test
const result = await service.createUser(user);
// Assert - Verify the expected outcome
expect(result.id).toBeDefined();
expect(result.email).toBe('test@example.com');
Naming Conventions
Test File Names
component.test.ts # Unit tests
component.spec.ts # Alternative convention
component.integration.ts # Integration tests
component.e2e.ts # End-to-end tests
Test Case Names
Use descriptive names that explain the scenario:
// Pattern: should [expected behavior] when [condition]
describe('UserService', () => {
describe('createUser', () => {
it('should create user when valid data provided', () => {});
it('should throw ValidationError when email is invalid', () => {});
it('should throw DuplicateError when email already exists', () => {});
});
});
BDD Style (Given-When-Then)
describe('User Registration', () => {
describe('given a valid email and password', () => {
describe('when the user submits the form', () => {
it('then creates a new account', () => {});
it('then sends a welcome email', () => {});
});
});
});
// BAD - vague assertionexpect(result).toBeTruthy();
// GOOD - specific assertionexpect(result.success).toBe(true);
expect(result.data.id).toBe('expected-id');
One Logical Assertion Per Test
// BAD - multiple unrelated assertionsit('should process order', () => {
expect(order.id).toBeDefined();
expect(order.total).toBe(100);
expect(emailService.send).toHaveBeenCalled();
expect(inventory.reduce).toHaveBeenCalled();
});
// GOOD - focused testsit('should assign an order ID', () => {
expect(order.id).toBeDefined();
});
it('should calculate correct total', () => {
expect(order.total).toBe(100);
});
it('should send confirmation email', () => {
expect(emailService.send).toHaveBeenCalled();
});
Custom Matchers
Create domain-specific matchers for readability:
expect.extend({
toBeValidEmail(received) {
const pass = /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(received);
return {
pass,
message: () =>`expected ${received} to be a valid email`
};
}
});
// Usageexpect('user@example.com').toBeValidEmail();
Edge Cases to Test
Input Validation
Empty/null/undefined inputs
Boundary values (0, -1, MAX_INT)
Invalid types
Malformed data
State Transitions
Initial state
After single operation
After multiple operations
After error and recovery
Async Operations
Successful completion
Timeout
Network errors
Concurrent operations
Race conditions
Error Handling
Expected errors (validation)
Unexpected errors (system)
Error recovery
Error propagation
Code Coverage Guidelines
Coverage Targets
Type
Target
Notes
Line Coverage
80%
Minimum acceptable
Branch Coverage
75%
Test all conditionals
Function Coverage
90%
All public APIs
Critical Paths
100%
Auth, payments, data integrity
Coverage Pitfalls
High coverage ≠ good tests
// 100% coverage but useless testit('should run without error', () => {
processOrder(order); // No assertions!
});
Focus on:
Business-critical paths
Edge cases and error handling
Integration points
Test Performance
Keep Tests Fast
Test Type
Target Time
Unit test
< 10ms
Integration test
< 1s
E2E test
< 30s
Full suite
< 5min
Parallelization
# Run tests in parallel
vitest --pool=threads
jest --maxWorkers=4
pytest -n auto
go test -parallel 4
