79:T652,// STUB: Returns predetermined responses class PaymentGatewayStub implements PaymentGateway { async processPayment(amount: Money): Promise { return { success: true, transactionId: "stub-txn-123" }; } } // MOCK: Verifies specific interactions test("should process payment with correct amount", async () => { const mockGateway = mock(); when(mockGateway.processPayment(anything())).thenResolve({ success: true, transactionId: "mock-123" }); const service = new OrderService(instance(mockGateway)); await service.checkout(orderId); verify(mockGateway.processPayment( deepEqual({ amount: 99.99, currency: "USD" }) )).once(); }); // FAKE: Simplified working implementation class InMemoryOrderRepository implements OrderRepository { private orders = new Map(); async save(order: Order): Promise { this.orders.set(order.id, order); } async findById(id: string): Promise { return this.orders.get(id) ?? null; } async findByStatus(status: OrderStatus): Promise { return [...this.orders.values()] .filter(o => o.status === status); } } // SPY: Records calls for inspection class NotificationServiceSpy implements NotificationService { private sentNotifications: Notification[] = []; async send(notification: Notification): Promise { this.sentNotifications.push(notification); } getSentNotifications(): Notification[] { return [...this.sentNotifications]; } wasCalled(): boolean { return this.sentNotifications.length > 0; } }7a:T62b,// STUB: Returns predetermined responses type PaymentGatewayStub struct{} func (s *PaymentGatewayStub) ProcessPayment(amount Money) (PaymentResult, error) { return PaymentResult{Success: true, TransactionID: "stub-txn-123"}, nil } // MOCK using testify/mock type MockPaymentGateway struct { mock.Mock } func (m *MockPaymentGateway) ProcessPayment(amount Money) (PaymentResult, error) { args := m.Called(amount) return args.Get(0).(PaymentResult), args.Error(1) } func TestCheckout_ProcessesPaymentCorrectly(t *testing.T) { mockGateway := new(MockPaymentGateway) mockGateway.On("ProcessPayment", Money{Amount: 99.99, Currency: "USD"}). Return(PaymentResult{Success: true, TransactionID: "mock-123"}, nil) service := NewOrderService(mockGateway) err := service.Checkout(orderID) assert.NoError(t, err) mockGateway.AssertExpectations(t) } // FAKE: In-memory implementation type InMemoryOrderRepository struct { orders map[string]*Order mu sync.RWMutex } func NewInMemoryOrderRepository() *InMemoryOrderRepository { return &InMemoryOrderRepository{orders: make(map[string]*Order)} } func (r *InMemoryOrderRepository) Save(ctx context.Context, order *Order) error { r.mu.Lock() defer r.mu.Unlock() r.orders[order.ID] = order return nil } func (r *InMemoryOrderRepository) FindByID(ctx context.Context, id string) (*Order, error) { r.mu.RLock() defer r.mu.RUnlock() if order, exists := r.orders[id]; exists { return order, nil } return nil, ErrOrderNotFound }7b:T125c,// Domain entity with complex business rules class Order { private items: OrderItem[] = []; private discount: Discount | null = null; private status: OrderStatus = OrderStatus.DRAFT; addItem(product: Product, quantity: number): void { if (this.status !== OrderStatus.DRAFT) { throw new OrderModificationError("Cannot modify confirmed order"); } if (quantity <= 0) { throw new InvalidQuantityError("Quantity must be positive"); } const existingItem = this.items.find(i => i.productId === product.id); if (existingItem) { existingItem.quantity += quantity; } else { this.items.push(new OrderItem(product.id, product.price, quantity)); } } applyDiscount(discount: Discount): void { if (this.status !== OrderStatus.DRAFT) { throw new OrderModificationError("Cannot modify confirmed order"); } if (discount.isExpired()) { throw new ExpiredDiscountError("Discount has expired"); } if (discount.minimumOrderValue && this.subtotal < discount.minimumOrderValue) { throw new MinimumNotMetError( `Order subtotal ${this.subtotal} below minimum ${discount.minimumOrderValue}` ); } this.discount = discount; } get total(): Money { const subtotal = this.subtotal; const discountAmount = this.calculateDiscountAmount(subtotal); return subtotal - discountAmount; } private calculateDiscountAmount(subtotal: Money): Money { if (!this.discount) return Money.zero(); if (this.discount.type === DiscountType.PERCENTAGE) { return subtotal.multiply(this.discount.value / 100); } return Money.min(this.discount.value, subtotal); // Don't go negative } } // Comprehensive unit tests for domain logic describe("Order", () => { describe("addItem", () => { it("should add new item to empty order", () => { const order = new Order(); const product = createProduct({ price: Money.of(29.99) }); order.addItem(product, 2); expect(order.items).toHaveLength(1); expect(order.subtotal).toEqual(Money.of(59.98)); }); it("should increment quantity for existing product", () => { const order = new Order(); const product = createProduct({ id: "prod-1", price: Money.of(10) }); order.addItem(product, 2); order.addItem(product, 3); expect(order.items).toHaveLength(1); expect(order.items[0].quantity).toBe(5); }); it("should reject zero quantity", () => { const order = new Order(); const product = createProduct(); expect(() => order.addItem(product, 0)).toThrow(InvalidQuantityError); }); it("should reject negative quantity", () => { const order = new Order(); const product = createProduct(); expect(() => order.addItem(product, -1)).toThrow(InvalidQuantityError); }); it("should reject modification after confirmation", () => { const order = createConfirmedOrder(); const product = createProduct(); expect(() => order.addItem(product, 1)).toThrow(OrderModificationError); }); }); describe("applyDiscount", () => { it("should apply percentage discount correctly", () => { const order = createOrderWithSubtotal(Money.of(100)); const discount = createPercentageDiscount(20); // 20% off order.applyDiscount(discount); expect(order.total).toEqual(Money.of(80)); }); it("should apply fixed amount discount correctly", () => { const order = createOrderWithSubtotal(Money.of(100)); const discount = createFixedDiscount(Money.of(15)); order.applyDiscount(discount); expect(order.total).toEqual(Money.of(85)); }); it("should cap discount at order subtotal", () => { const order = createOrderWithSubtotal(Money.of(10)); const discount = createFixedDiscount(Money.of(50)); // More than order value order.applyDiscount(discount); expect(order.total).toEqual(Money.of(0)); // Not negative }); it("should reject expired discount", () => { const order = createOrderWithSubtotal(Money.of(100)); const expiredDiscount = createExpiredDiscount(); expect(() => order.applyDiscount(expiredDiscount)) .toThrow(ExpiredDiscountError); }); it("should enforce minimum order value", () => { const order = createOrderWithSubtotal(Money.of(25)); const discount = createDiscountWithMinimum(Money.of(50)); expect(() => order.applyDiscount(discount)) .toThrow(MinimumNotMetError); }); }); });7c:T7cb,// Test Data Builder pattern - fluent interface for test objects class OrderBuilder { private order: Partial = { id: generateId(), status: OrderStatus.DRAFT, items: [], createdAt: new Date(), }; static anOrder(): OrderBuilder { return new OrderBuilder(); } withId(id: string): this { this.order.id = id; return this; } withStatus(status: OrderStatus): this { this.order.status = status; return this; } withItems(items: OrderItem[]): this { this.order.items = items; return this; } withItem(product: Product, quantity: number): this { this.order.items = [ ...(this.order.items || []), new OrderItem(product.id, product.price, quantity), ]; return this; } withSubtotal(amount: Money): this { // Create enough items to reach the subtotal this.order.items = [new OrderItem("test-product", amount, 1)]; return this; } confirmed(): this { this.order.status = OrderStatus.CONFIRMED; this.order.confirmedAt = new Date(); return this; } build(): Order { return Order.fromData(this.order as OrderData); } } // Usage in tests - highly readable describe("Order cancellation", () => { it("should allow cancellation within grace period", () => { const order = OrderBuilder.anOrder() .confirmed() .withItems([item1, item2]) .build(); // ...test logic }); }); // Object Mother pattern - pre-built common scenarios class OrderMother { static draftOrderWithTwoItems(): Order { return OrderBuilder.anOrder() .withItem(ProductMother.aBook(), 1) .withItem(ProductMother.aGadget(), 2) .build(); } static confirmedOrderWorthOver100(): Order { return OrderBuilder.anOrder() .withSubtotal(Money.of(150)) .confirmed() .build(); } static expiredOrder(): Order { return OrderBuilder.anOrder() .withStatus(OrderStatus.EXPIRED) .build(); } }7d:T1740,// Express handler with proper separation of concerns class OrderController { constructor( private readonly orderService: OrderService, private readonly authService: AuthService ) {} async createOrder(req: Request, res: Response, next: NextFunction) { try { // Parse and validate request const createOrderDto = CreateOrderSchema.parse(req.body); const userId = req.user!.id; // Set by auth middleware // Delegate to service const order = await this.orderService.createOrder(userId, createOrderDto); // Return response res.status(201).json({ success: true, data: OrderResponseDto.fromDomain(order), }); } catch (error) { next(error); // Let error middleware handle it } } async getOrder(req: Request, res: Response, next: NextFunction) { try { const orderId = req.params.orderId; const userId = req.user!.id; const order = await this.orderService.getOrder(orderId); // Authorization check if (order.userId !== userId && !req.user!.isAdmin) { throw new ForbiddenError("Cannot access order belonging to another user"); } res.json({ success: true, data: OrderResponseDto.fromDomain(order), }); } catch (error) { if (error instanceof OrderNotFoundError) { res.status(404).json({ success: false, error: "Order not found" }); } else { next(error); } } } } // Unit tests for controller - service is mocked describe("OrderController", () => { let controller: OrderController; let mockOrderService: jest.Mocked; let mockAuthService: jest.Mocked; let mockRequest: Partial; let mockResponse: Partial; let mockNext: jest.Mock; beforeEach(() => { mockOrderService = { createOrder: jest.fn(), getOrder: jest.fn(), } as any; mockAuthService = {} as any; controller = new OrderController(mockOrderService, mockAuthService); mockResponse = { status: jest.fn().mockReturnThis(), json: jest.fn(), }; mockNext = jest.fn(); }); describe("createOrder", () => { it("should return 201 with created order on success", async () => { const createDto = { items: [{ productId: "p1", quantity: 2 }] }; const createdOrder = OrderMother.draftOrderWithTwoItems(); mockOrderService.createOrder.mockResolvedValue(createdOrder); mockRequest = { body: createDto, user: { id: "user-123" }, }; await controller.createOrder( mockRequest as Request, mockResponse as Response, mockNext ); expect(mockResponse.status).toHaveBeenCalledWith(201); expect(mockResponse.json).toHaveBeenCalledWith({ success: true, data: expect.objectContaining({ id: createdOrder.id, }), }); }); it("should pass validation errors to error middleware", async () => { mockRequest = { body: { items: [] }, // Invalid - empty items user: { id: "user-123" }, }; await controller.createOrder( mockRequest as Request, mockResponse as Response, mockNext ); expect(mockNext).toHaveBeenCalledWith(expect.any(z.ZodError)); }); it("should call service with correct parameters", async () => { const createDto = { items: [{ productId: "p1", quantity: 2 }] }; mockOrderService.createOrder.mockResolvedValue(OrderMother.draftOrderWithTwoItems()); mockRequest = { body: createDto, user: { id: "user-456" }, }; await controller.createOrder( mockRequest as Request, mockResponse as Response, mockNext ); expect(mockOrderService.createOrder).toHaveBeenCalledWith("user-456", createDto); }); }); describe("getOrder", () => { it("should return 404 when order not found", async () => { mockOrderService.getOrder.mockRejectedValue(new OrderNotFoundError("order-999")); mockRequest = { params: { orderId: "order-999" }, user: { id: "user-123", isAdmin: false }, }; await controller.getOrder( mockRequest as Request, mockResponse as Response, mockNext ); expect(mockResponse.status).toHaveBeenCalledWith(404); expect(mockResponse.json).toHaveBeenCalledWith({ success: false, error: "Order not found", }); }); it("should return 403 when accessing another user's order", async () => { const otherUsersOrder = OrderBuilder.anOrder() .withId("order-123") .build(); Object.assign(otherUsersOrder, { userId: "other-user" }); mockOrderService.getOrder.mockResolvedValue(otherUsersOrder); mockRequest = { params: { orderId: "order-123" }, user: { id: "current-user", isAdmin: false }, }; await controller.getOrder( mockRequest as Request, mockResponse as Response, mockNext ); expect(mockNext).toHaveBeenCalledWith(expect.any(ForbiddenError)); }); it("should allow admin to access any order", async () => { const otherUsersOrder = OrderBuilder.anOrder().build(); Object.assign(otherUsersOrder, { userId: "other-user" }); mockOrderService.getOrder.mockResolvedValue(otherUsersOrder); mockRequest = { params: { orderId: "order-123" }, user: { id: "admin-user", isAdmin: true }, }; await controller.getOrder( mockRequest as Request, mockResponse as Response, mockNext ); expect(mockResponse.json).toHaveBeenCalledWith( expect.objectContaining({ success: true }) ); }); }); });7e:T128b,// Event handler with proper error handling and idempotency class PaymentCompletedHandler { constructor( private readonly orderRepository: OrderRepository, private readonly eventPublisher: EventPublisher, private readonly idempotencyStore: IdempotencyStore, private readonly logger: Logger ) {} async handle(event: PaymentCompletedEvent): Promise { // Idempotency check const idempotencyKey = `payment-completed:${event.paymentId}`; if (await this.idempotencyStore.exists(idempotencyKey)) { this.logger.info("Duplicate event ignored", { paymentId: event.paymentId }); return; } // Find and update order const order = await this.orderRepository.findById(event.orderId); if (!order) { this.logger.warn("Order not found for payment", { orderId: event.orderId, paymentId: event.paymentId }); throw new OrderNotFoundError(event.orderId); } // Process the payment confirmation order.confirmPayment(event.paymentId, event.amount); await this.orderRepository.save(order); // Publish downstream events await this.eventPublisher.publish(new OrderPaidEvent({ orderId: order.id, paymentId: event.paymentId, paidAt: event.completedAt, })); // Mark as processed await this.idempotencyStore.mark(idempotencyKey, { processedAt: new Date(), orderId: order.id }); } } // Comprehensive unit tests describe("PaymentCompletedHandler", () => { let handler: PaymentCompletedHandler; let mockOrderRepository: jest.Mocked; let mockEventPublisher: jest.Mocked; let mockIdempotencyStore: jest.Mocked; let mockLogger: jest.Mocked; beforeEach(() => { mockOrderRepository = { findById: jest.fn(), save: jest.fn(), } as any; mockEventPublisher = { publish: jest.fn() }; mockIdempotencyStore = { exists: jest.fn().mockResolvedValue(false), mark: jest.fn() }; mockLogger = { info: jest.fn(), warn: jest.fn() } as any; handler = new PaymentCompletedHandler( mockOrderRepository, mockEventPublisher, mockIdempotencyStore, mockLogger ); }); it("should update order status and publish OrderPaidEvent", async () => { const order = OrderBuilder.anOrder().withStatus(OrderStatus.PENDING).build(); const event = new PaymentCompletedEvent({ paymentId: "pay-123", orderId: order.id, amount: Money.of(99.99), completedAt: new Date(), }); mockOrderRepository.findById.mockResolvedValue(order); await handler.handle(event); expect(mockOrderRepository.save).toHaveBeenCalledWith( expect.objectContaining({ status: OrderStatus.PAID }) ); expect(mockEventPublisher.publish).toHaveBeenCalledWith( expect.objectContaining({ type: "OrderPaidEvent", data: expect.objectContaining({ orderId: order.id }), }) ); }); it("should ignore duplicate events", async () => { mockIdempotencyStore.exists.mockResolvedValue(true); const event = createPaymentCompletedEvent(); await handler.handle(event); expect(mockOrderRepository.findById).not.toHaveBeenCalled(); expect(mockEventPublisher.publish).not.toHaveBeenCalled(); expect(mockLogger.info).toHaveBeenCalledWith( "Duplicate event ignored", expect.any(Object) ); }); it("should throw when order not found", async () => { mockOrderRepository.findById.mockResolvedValue(null); const event = createPaymentCompletedEvent({ orderId: "nonexistent" }); await expect(handler.handle(event)).rejects.toThrow(OrderNotFoundError); expect(mockEventPublisher.publish).not.toHaveBeenCalled(); expect(mockIdempotencyStore.mark).not.toHaveBeenCalled(); }); it("should mark event as processed after success", async () => { const order = createPendingOrder(); mockOrderRepository.findById.mockResolvedValue(order); const event = createPaymentCompletedEvent({ paymentId: "pay-456", orderId: order.id }); await handler.handle(event); expect(mockIdempotencyStore.mark).toHaveBeenCalledWith( "payment-completed:pay-456", expect.objectContaining({ orderId: order.id }) ); }); it("should not mark event as processed on failure", async () => { mockOrderRepository.findById.mockRejectedValue(new DatabaseError("Connection lost")); const event = createPaymentCompletedEvent(); await expect(handler.handle(event)).rejects.toThrow(DatabaseError); expect(mockIdempotencyStore.mark).not.toHaveBeenCalled(); }); });7f:Ta58,// Well-organized test file following AAA pattern describe("OrderService", () => { // Group by feature, not by method describe("Order Creation", () => { describe("with valid input", () => { it("should create order with correct initial status", () => { // Arrange const service = createOrderService(); const input = validOrderInput(); // Act const order = service.createOrder(input); // Assert expect(order.status).toBe(OrderStatus.DRAFT); }); it("should calculate subtotal from items", () => { // Arrange const service = createOrderService(); const input = orderInputWith([ { productId: "p1", price: 10, quantity: 2 }, { productId: "p2", price: 5, quantity: 3 }, ]); // Act const order = service.createOrder(input); // Assert expect(order.subtotal).toEqual(Money.of(35)); }); }); describe("with invalid input", () => { it.each([ { field: "items", value: [], error: "Order must have at least one item" }, { field: "items", value: null, error: "Items are required" }, { field: "customerId", value: "", error: "Customer ID is required" }, ])("should reject when $field is $value", ({ field, value, error }) => { const service = createOrderService(); const input = { ...validOrderInput(), [field]: value }; expect(() => service.createOrder(input)).toThrow(error); }); }); }); describe("Order Confirmation", () => { it("should transition status from DRAFT to CONFIRMED", () => { const service = createOrderService(); const order = createDraftOrder(); service.confirmOrder(order.id); expect(order.status).toBe(OrderStatus.CONFIRMED); }); it("should reject confirmation of already confirmed order", () => { const service = createOrderService(); const order = createConfirmedOrder(); expect(() => service.confirmOrder(order.id)) .toThrow("Order is already confirmed"); }); }); }); // Shared test utilities in separate file // test/helpers/order-helpers.ts export function createOrderService(overrides: Partial = {}) { return new OrderService({ orderRepository: new InMemoryOrderRepository(), eventPublisher: new NoOpEventPublisher(), ...overrides, }); } export function validOrderInput(): CreateOrderInput { return { customerId: "cust-123", items: [{ productId: "prod-1", quantity: 1 }], }; }71:{"json":{"id":"seed_7d9dfbc2344f90db283af4113a9fec9e","slug":"testing-microservices","category":"System Design (HLD)","topic":"Testing Microservices","title":"Testing Microservices","description":"Master the art and science of testing distributed microservices architectures. Learn unit testing, integration testing, contract testing, end-to-end testing strategies, and how to design effective test environments that ensure reliability at scale.","difficulty":"ADVANCED","estimatedMinutes":90,"pages":[{"id":"seed_1d8ae8192dbd3268f8ebdced27ed270f","title":"Unit Testing Services","order":0,"content":[{"id":"opening-hook","title":"The Foundation of Microservices Quality","content":[{"data":{"content":"In a microservices architecture, where dozens or hundreds of services interact in complex choreographies, **unit testing becomes your first and most critical line of defense**. Unlike monolithic applications where a single test suite can exercise broad swaths of functionality, microservices demand a fundamentally different approach—one where each service must be verifiable in complete isolation, yet provide confidence that it will behave correctly when composed with others.\n\nUnit testing in microservices isn't just about testing functions or classes. It's about establishing **behavioral contracts** that each service must honor, creating a foundation of trust that enables the entire distributed system to evolve with confidence."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand how to design and implement effective unit testing strategies for microservices, including isolation techniques, test doubles, domain logic testing, and how to structure test suites that remain maintainable as services evolve. You'll learn patterns used by elite engineering teams at companies like Netflix, Amazon, and Google to ensure individual service quality.","variant":"info"},"type":"callout"}]},{"id":"unit-testing-philosophy","title":"The Unit Testing Philosophy in Microservices","content":[{"data":{"content":"Unit testing in microservices requires a subtle but important shift in thinking. In traditional monolithic applications, a 'unit' typically refers to a single function, method, or class. In microservices, the definition expands to include **the service as a unit of behavior**—while still testing its internal components in isolation.\n\nThis dual perspective is essential:\n\n**Component-Level Unit Testing:** Testing individual classes, functions, and modules within a service to verify their logic is correct.\n\n**Behavioral Unit Testing:** Testing the service's public interfaces (APIs, event handlers, message consumers) with all external dependencies mocked or stubbed, to verify the service implements its contract correctly.\n\nBoth levels are necessary. Component-level tests catch logic bugs early. Behavioral tests ensure the service fulfills its responsibilities to the broader system."},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Unit Boundary Decision","content":"A critical design decision is where to draw the unit boundary. Too narrow (testing individual methods in isolation) leads to brittle tests that break with refactoring. Too broad (testing multiple components together) slows execution and obscures failure causes. The sweet spot: test behavioral units—classes or modules that represent a coherent piece of functionality, with clear inputs and outputs.","variant":"tip"},"type":"callout"},{"data":{"rows":[["Method/Function","Single function logic","All mocked","< 1ms","Complete"],["Class/Module","Class behavior with collaborators","External only mocked","< 10ms","High"],["Component","Domain logic unit","I/O mocked","< 100ms","Medium-High"],["Service Behavioral","API/Event handlers","All external mocked","< 500ms","Medium"]],"caption":"Unit Testing Scope in Microservices","headers":["Test Level","What's Tested","External Dependencies","Speed","Isolation"]},"type":"table"},{"data":{"content":"**The Testing Pyramid in Microservices Context:**\n\nThe classic testing pyramid—many unit tests, fewer integration tests, even fewer E2E tests—remains valid but requires adaptation for microservices:\n\n- **Base (Unit Tests):** Fast, numerous, focused on business logic. These run in milliseconds and catch the majority of bugs.\n- **Middle (Integration Tests):** Test service interactions with real dependencies (databases, caches). Slower but essential for I/O correctness.\n- **Top (Contract & E2E Tests):** Verify service interactions and end-to-end flows. Slowest but provide system-level confidence.\n\nThe key insight: in microservices, the pyramid is **replicated for each service**. Every service has its own pyramid, and the aggregate provides system-wide quality assurance."},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"what-to-unit-test","title":"What to Unit Test in a Microservice","content":[{"data":{"content":"Not all code in a microservice merits equal testing attention. Strategic focus on high-value targets maximizes quality impact per testing effort. Understanding what to test—and what not to test—is a hallmark of mature engineering teams.\n\n**High-Priority Unit Test Targets:**"},"type":"text"},{"data":{"items":["**Domain Logic (Business Rules):** The heart of your service—validation rules, calculations, state machines, business constraints. These are pure functions or classes that encode what makes your service valuable. High complexity, high test value.","**Data Transformation:** Mappers, serializers, and transformers that convert between representations (DTOs, domain objects, events). Subtle bugs here cause cascading failures across services.","**Error Handling Paths:** Edge cases, invalid inputs, and failure scenarios. Unit tests excel at exercising paths that rarely occur in production but cause catastrophic failures when they do.","**API Request/Response Contracts:** Ensure your service accepts expected inputs and returns correctly structured outputs. These tests serve as executable documentation.","**Event Handlers and Message Processors:** Verify that incoming events trigger correct behaviors. Mock external side effects, focus on decision logic."],"title":{"icon":"CheckCircle","text":"Core Testing Priorities","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**Lower-Priority Unit Test Targets:**"},"type":"text"},{"data":{"items":["**Simple CRUD Operations:** Basic create/read/update/delete with minimal logic. These are better served by integration tests that verify actual database behavior.","**Framework Boilerplate:** Testing that your DI container wires correctly or that decorators work as expected tests the framework, not your code.","**Third-Party Library Wrappers:** Thin wrappers around external libraries add little value as unit test targets unless they contain significant adaptation logic.","**Configuration Loading:** Unless configuration parsing contains business rules, it's better verified by integration or smoke tests."],"title":{"icon":"Info","text":"Lower Priority Areas","type":"icon","color":"secondary","variant":"outline-circle"},"variant":"default"},"type":"list"},{"data":{"icon":"AlertCircle","title":"The Test Coverage Trap","content":"High code coverage doesn't equal high-quality tests. 100% coverage with shallow assertion-free tests provides false confidence. Focus on testing behavior, not lines of code. A well-designed test suite might have 70% coverage but catch 95% of bugs because it targets the right code with meaningful assertions.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"test-doubles","title":"Test Doubles: Mocks, Stubs, and Fakes","content":[{"data":{"content":"Test doubles are the essential tools for achieving isolation in unit tests. They replace real dependencies with controlled substitutes, allowing you to test a unit's behavior independent of its collaborators. Understanding the distinctions and appropriate use cases for each type is fundamental to effective microservices testing.\n\n**The Test Double Taxonomy:**"},"type":"text"},{"data":{"rows":[["Dummy","Objects passed but never used","Satisfy parameter requirements","None"],["Stub","Provides canned answers to calls","Control indirect inputs","None (state verification)"],["Spy","Records calls for later inspection","Verify interactions happened","Call recording"],["Mock","Pre-programmed with expectations","Verify specific interactions","Behavior verification"],["Fake","Working implementation simplified","Complex dependencies needing behavior","May verify state or behavior"]],"caption":"Types of Test Doubles","headers":["Type","Definition","Use Case","Verification"]},"type":"table"},{"data":{"fileName":"test-doubles-example","languages":[{"code":"$79","label":"TypeScript","value":"typescript"},{"code":"$7a","label":"Go","value":"go"}]},"type":"code"},{"data":{"content":"**Choosing the Right Test Double:**\n\n- **Use Stubs** when you need to control what a dependency returns but don't care how it's called. Stubs are ideal for setting up test scenarios (e.g., 'what happens when the database returns empty results?').\n\n- **Use Mocks** when the interaction itself is what you're testing—verifying that your code calls the right method with the right arguments in the right sequence. Overusing mocks leads to brittle tests.\n\n- **Use Fakes** for complex dependencies that are expensive to mock fully. In-memory databases, file systems, and message queues are common fake candidates. Fakes require maintenance but provide more realistic behavior.\n\n- **Use Spies** when you need to observe behavior without constraining it. Spies are less prescriptive than mocks—they record what happened for later assertion."},"type":"text"},{"data":{"icon":"Info","title":"Mock Overuse Anti-Pattern","content":"Excessive mocking is a code smell. If you're mocking everything, your unit under test may have too many dependencies—a sign of poor design. Well-designed services have a core of pure business logic with minimal dependencies, surrounded by an 'infrastructure shell' that handles I/O. The pure core is easily unit-tested; the shell is integration-tested.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"testing-domain-logic","title":"Testing Domain Logic","content":[{"data":{"content":"Domain logic—the business rules and calculations that define your service's core value—demands the most rigorous unit testing attention. This code changes frequently, contains subtle edge cases, and directly impacts business outcomes when incorrect.\n\n**Principles for Domain Logic Testing:**\n\n1. **Test Behavior, Not Implementation:** Assert on outcomes, not internal state or method call sequences. Tests should describe what the system does, not how.\n\n2. **Use Domain Language:** Test names and assertions should use business terminology. 'test_order_with_expired_coupon_does_not_apply_discount' is clearer than 'test_validateCoupon_returns_false'.\n\n3. **Cover Edge Cases Exhaustively:** Business rules often have complex boundary conditions. What happens at midnight? On leap years? With empty collections? Zero amounts?"},"type":"text"},{"data":{"fileName":"domain-logic-testing","languages":[{"code":"$7b","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"content":"**Test Data Builders and Object Mothers:**\n\nDomain tests require constructing complex objects in specific states. Using raw constructors leads to verbose, brittle tests. Instead, use **Test Data Builders** or **Object Mothers** to create readable, maintainable test fixtures."},"type":"text"},{"data":{"fileName":"test-data-builders","languages":[{"code":"$7c","label":"TypeScript","value":"typescript"}]},"type":"code"}],"titleType":"number","titleNumber":4},{"id":"testing-api-handlers","title":"Testing API Handlers","content":[{"data":{"content":"API handlers are the entry points to your microservice—they receive HTTP requests, coordinate service logic, and return responses. Unit testing handlers requires a careful balance: you want to verify the request/response contract without testing the underlying business logic (which has its own unit tests).\n\n**What API Handler Unit Tests Should Verify:**\n\n- **Request Parsing:** That path parameters, query strings, headers, and body are correctly extracted and validated.\n- **Response Structure:** That responses have correct status codes, headers, and body structure.\n- **Error Mapping:** That domain errors are translated to appropriate HTTP errors.\n- **Authorization Checks:** That handlers enforce required permissions (with auth mocked)."},"type":"text"},{"data":{"fileName":"api-handler-testing","languages":[{"code":"$7d","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"Lightbulb","title":"Test Request/Response, Not Implementation","content":"API handler unit tests should focus on the HTTP contract: 'Given this request, expect this response.' Avoid testing internal wiring like 'verify the controller called the service with these exact arguments'—such tests break with refactoring and don't add value beyond the contract tests.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"testing-event-handlers","title":"Testing Event and Message Handlers","content":[{"data":{"content":"In event-driven microservices, message handlers are as important as API handlers—they receive events from other services and trigger internal processing. Unit testing these handlers requires mocking the message infrastructure while verifying the handler's behavior.\n\n**Key Testing Concerns for Event Handlers:**\n\n- **Event Deserialization:** Correct parsing of event payloads, including handling of missing or extra fields.\n- **Idempotency:** Handling duplicate events gracefully without corrupting state.\n- **Error Handling:** Appropriate behavior on processing failures (retry, dead-letter, ignore).\n- **Side Effects:** Verifying that handlers produce expected outcomes (state changes, commands, new events)."},"type":"text"},{"data":{"fileName":"event-handler-testing","languages":[{"code":"$7e","label":"TypeScript","value":"typescript"}]},"type":"code"}],"titleType":"number","titleNumber":6},{"id":"test-organization","title":"Test Organization and Maintenance","content":[{"data":{"content":"A well-organized test suite is as important as well-organized production code. As services evolve, poorly structured tests become a maintenance burden that slows development rather than enabling it.\n\n**Organizing Test Files:**\n\nFollow the mirror structure convention—test files mirror the source structure:\n\n```\nsrc/\n orders/\n order.ts\n order-service.ts\n handlers/\n create-order-handler.ts\ntest/\n orders/\n order.test.ts\n order-service.test.ts\n handlers/\n create-order-handler.test.ts\n```\n\nAlternatively, co-locate tests with source files for easier navigation:\n\n```\nsrc/\n orders/\n order.ts\n order.test.ts\n order-service.ts\n order-service.test.ts\n```\n\nBoth approaches work; consistency within a codebase matters most."},"type":"text"},{"data":{"items":["**Use descriptive names:** `should_apply_discount_when_coupon_is_valid` > `test1`","**State the scenario:** `given_expired_session_when_accessing_resource_then_returns_401`","**Group by behavior:** Organize tests by what they verify, not by method name","**Keep tests focused:** One logical assertion per test (multiple assertions are fine if they verify one behavior)","**Use AAA pattern:** Arrange, Act, Assert sections clearly delineated"],"title":{"icon":"CheckCircle","text":"Test Naming Best Practices","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"fileName":"test-organization-example","languages":[{"code":"$7f","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"Info","title":"Test Maintenance Anti-Patterns","content":"**Avoid these patterns that make tests hard to maintain:**\n\n• **Shared mutable state between tests:** Each test should set up its own fixtures\n• **Magic numbers/strings:** Use named constants or builders\n• **Over-mocking:** If setup is complex, the code may need refactoring\n• **Testing implementation details:** Focus on public interfaces and behavior\n• **Copy-paste test code:** Extract common setup into helpers","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Unit Testing Services","content":[{"data":{"content":"Unit testing in microservices is both an art and a discipline. When done well, it creates a safety net that enables rapid, confident evolution of individual services. When done poorly, it becomes a maintenance burden that slows development without providing proportional value."},"type":"text"},{"data":{"type":"ordered","items":["**Define unit boundaries strategically:** Test behavioral units—classes or modules that represent coherent functionality—not individual methods in isolation.","**Prioritize domain logic:** Business rules and calculations deserve the most thorough testing. Infrastructure code is better validated by integration tests.","**Choose test doubles wisely:** Use stubs to control inputs, mocks to verify critical interactions, and fakes for complex dependencies that need real behavior.","**Test behavior, not implementation:** Assert on outcomes and contracts, not on internal state or call sequences. This keeps tests valuable through refactoring.","**Organize for maintainability:** Use descriptive names, follow AAA pattern, group by behavior, and extract common fixtures into helpers.","**Aim for high-value coverage:** 100% coverage isn't the goal—thorough testing of high-risk, high-complexity code is."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nUnit tests verify that individual components work correctly in isolation, but microservices must interact with databases, caches, message brokers, and other external systems. The next page explores **Integration Testing**—how to verify that your service correctly integrates with its infrastructure dependencies, catching the bugs that unit tests with mocked dependencies would miss."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand how to design and implement effective unit testing strategies for microservices. You've learned about test doubles, domain logic testing, API and event handler testing, and test organization. Next, we'll explore how to verify service behavior with real infrastructure through integration testing.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_957bb57210445113e4391908dca47205","title":"Integration Testing","order":1,"content":null,"isLocked":true},{"id":"seed_aafef82ef2b9f7bfc6e5396e6c859b99","title":"Contract Testing","order":2,"content":null,"isLocked":true},{"id":"seed_3aadf3d21e7aa41721a5ae61046dc50b","title":"End-to-End Testing","order":3,"content":null,"isLocked":true},{"id":"seed_3e0ac8fb0af6db1848012913fc4c8011","title":"Test Environments","order":4,"content":null,"isLocked":true}]}}