En praktisk teststrategi til virkelige applikationer

·2 min. læsning
testingqualitybest-practices

Introduktion

“Vi har brug for flere tests” er let at sige, men svært at gøre godt. Jeg har set teams med 90 % kodedækning, der stadig sender fejl ud, og teams med 50 % dækning, der sjældent har produktionsproblemer.

Forskellen ligger ikke i mængden af tests - den ligger i strategien bag dem.

Testpyramiden (genbesøgt)

Den klassiske testpyramide foreslår:

  • Mange unit-tests (hurtige, isolerede)
  • Nogle integrationstests (langsommere, tester interaktioner)
  • Få E2E-tests (langsomst, tester fulde flows)

Det er et godt udgangspunkt, men det er ikke hele historien.

Problemet med rene unit-tests

// 100 % unit-testdækning, men virker det?
class OrderService {
  constructor(
    private inventory: InventoryService,
    private payment: PaymentService,
    private shipping: ShippingService
  ) {}

  async createOrder(order: Order): Promise<OrderResult> {
    await this.inventory.reserve(order.items);
    await this.payment.charge(order.total);
    await this.shipping.schedule(order);
    return { success: true };
  }
}

// Unit-test med mocks
test('createOrder calls all services', async () => {
  const inventory = mock<InventoryService>();
  const payment = mock<PaymentService>();
  const shipping = mock<ShippingService>();
  
  const service = new OrderService(inventory, payment, shipping);
  await service.createOrder(testOrder);
  
  expect(inventory.reserve).toHaveBeenCalled();
  expect(payment.charge).toHaveBeenCalled();
  expect(shipping.schedule).toHaveBeenCalled();
});

Denne test bestås, men den fortæller os ikke, om systemet reelt fungerer. Mocks matcher måske ikke den virkelige adfærd.

Min teststrategi

Niveau 1: Unit-tests for ren logik

Test rene funktioner og forretningslogik uden afhængigheder:

// Ren funktion - nem at teste
function calculateOrderTotal(items: OrderItem[], discount: Discount): number {
  const subtotal = items.reduce((sum, item) => sum + item.price * item.quantity, 0);
  return applyDiscount(subtotal, discount);
}

test('calculateOrderTotal applies percentage discount', () => {
  const items = [{ price: 100, quantity: 2 }];
  const discount = { type: 'percentage', value: 10 };
  
  expect(calculateOrderTotal(items, discount)).toBe(180);
});

test('calculateOrderTotal handles empty cart', () => {
  expect(calculateOrderTotal([], null)).toBe(0);
});

Niveau 2: Integrationstests for komponenter

Test komponenter med rigtige afhængigheder (database, cache), men mock eksterne services:

describe('OrderRepository', () => {
  let db: TestDatabase;
  let repository: OrderRepository;

  beforeAll(async () => {
    db = await TestDatabase.create();
    repository = new OrderRepository(db);
  });

  afterAll(() => db.destroy());

  beforeEach(() => db.clear());

  test('creates and retrieves order', async () => {
    const order = await repository.create({
      userId: 'user_123',
      items: [{ productId: 'prod_1', quantity: 2 }]
    });

    const retrieved = await repository.findById(order.id);
    
    expect(retrieved).toMatchObject({
      userId: 'user_123',
      items: expect.arrayContaining([
        expect.objectContaining({ productId: 'prod_1' })
      ])
    });
  });

  test('finds orders by user', async () => {
    await repository.create({ userId: 'user_123', items: [] });
    await repository.create({ userId: 'user_123', items: [] });
    await repository.create({ userId: 'user_456', items: [] });

    const orders = await repository.findByUser('user_123');
    
    expect(orders).toHaveLength(2);
  });
});

Niveau 3: API-tests for services

Test dine API-endpoints med en rigtig server, men kontrollerede afhængigheder:

describe('POST /api/orders', () => {
  let app: TestApp;

  beforeAll(async () => {
    app = await TestApp.create({
      // Rigtig database
      database: testDb,
      // Mock eksterne services
      paymentProvider: mockPaymentProvider,
      inventoryService: mockInventoryService
    });
  });

  test('creates order successfully', async () => {
    mockInventoryService.checkAvailability.mockResolvedValue(true);
    mockPaymentProvider.charge.mockResolvedValue({ success: true });

    const response = await app.post('/api/orders', {
      items: [{ productId: 'prod_1', quantity: 1 }],
      paymentMethod: 'card_123'
    });

    expect(response.status).toBe(201);
    expect(response.body).toMatchObject({
      id: expect.any(String),
      status: 'confirmed'
    });
  });

  test('returns 400 for invalid input', async () => {
    const response = await app.post('/api/orders', {
      items: [] // Tom indkøbskurv
    });

    expect(response.status).toBe(400);
    expect(response.body.error).toContain('items');
  });

  test('returns 402 when payment fails', async () => {
    mockInventoryService.checkAvailability.mockResolvedValue(true);
    mockPaymentProvider.charge.mockResolvedValue({ 
      success: false, 
      error: 'Card declined' 
    });

    const response = await app.post('/api/orders', {
      items: [{ productId: 'prod_1', quantity: 1 }],
      paymentMethod: 'card_123'
    });

    expect(response.status).toBe(402);
  });
});

Niveau 4: E2E-tests for kritiske stier

Test komplette brugerrejser for dine vigtigste flows:

describe('Checkout Flow', () => {
  test('user can complete purchase', async () => {
    // Opsætning
    const user = await createTestUser();
    const product = await createTestProduct({ price: 99.99 });
    
    // Læg i kurv
    await api.post('/cart/items', { productId: product.id }, { as: user });
    
    // Checkout
    const order = await api.post('/checkout', {
      paymentMethod: testCard,
      shippingAddress: testAddress
    }, { as: user });
    
    // Verificér
    expect(order.status).toBe('confirmed');
    
    // Tjek sideeffekter
    const inventory = await getProductInventory(product.id);
    expect(inventory.reserved).toBe(1);
    
    const email = await getLastEmailTo(user.email);
    expect(email.subject).toContain('Order Confirmation');
  });
});

Hvad du skal teste

Test altid

  • Forretningslogik: Beregninger, validering, tilstandsmaskiner
  • Kantsager: Tomme input, grænseværdier, fejltilstande
  • Kritiske stier: Checkout, autentificering, betaling
  • Fejlrettelser: Enhver fejlrettelse bør komme med en test

Test nogle gange

  • Integrationspunkter: Databaseforespørgsler, API-kald
  • Komplekse UI-interaktioner: Flertrinsformularer, drag-and-drop

Test sjældent

  • Simpel CRUD: Hvis det blot videresender data, dækker integrationstests det
  • Tredjepartsbiblioteker: Stol på, at de fungerer
  • Implementeringsdetaljer: Test adfærd, ikke hvordan den er implementeret

Antimønstre inden for testning

At teste implementeringsdetaljer

// Dårligt - tester implementeringen
test('uses cache before database', async () => {
  await service.getUser('123');
  
  expect(cache.get).toHaveBeenCalledBefore(database.query);
});

// Godt - tester adfærden
test('returns user data', async () => {
  const user = await service.getUser('123');
  
  expect(user).toMatchObject({ id: '123', name: 'John' });
});

Overdreven mocking

// Dårligt - mocker alt
test('processOrder', async () => {
  const mockDb = mock<Database>();
  const mockCache = mock<Cache>();
  const mockLogger = mock<Logger>();
  const mockMetrics = mock<Metrics>();
  // ... 10 flere mocks
  
  // Denne test fortæller os intet om den reelle adfærd
});

// Godt - brug rigtige afhængigheder, hvor det er praktisk
test('processOrder', async () => {
  const service = new OrderService(realDb, realCache);
  // Mock kun eksterne services
  service.paymentProvider = mockPaymentProvider;
  
  const result = await service.processOrder(testOrder);
  
  // Verificér den rigtige databasetilstand
  const saved = await realDb.orders.findById(result.id);
  expect(saved.status).toBe('confirmed');
});

Flaky tests

Tests, der nogle gange bestås og nogle gange fejler, er værre end ingen tests:

// Dårligt - afhængig af timing
test('debounces search', async () => {
  input.type('hello');
  await sleep(300);
  expect(searchCalled).toBe(false);
  await sleep(200);
  expect(searchCalled).toBe(true);
});

// Godt - brug fake timers
test('debounces search', async () => {
  jest.useFakeTimers();
  
  input.type('hello');
  jest.advanceTimersByTime(300);
  expect(searchCalled).toBe(false);
  
  jest.advanceTimersByTime(200);
  expect(searchCalled).toBe(true);
});

Testorganisering

Filstruktur

src/
├── orders/
│   ├── order.service.ts
│   ├── order.service.test.ts      # Unit-tests
│   ├── order.repository.ts
│   └── order.repository.test.ts   # Integrationstests
└── __tests__/
    ├── api/
    │   └── orders.api.test.ts     # API-tests
    └── e2e/
        └── checkout.e2e.test.ts   # E2E-tests
describe('OrderService', () => {
  describe('createOrder', () => {
    test('creates order with valid input', () => {});
    test('throws ValidationError for empty cart', () => {});
    test('reserves inventory before charging payment', () => {});
  });
});

Kontinuerlig integration

Hurtig feedback-loop

# Kør ved hvert push
test:unit:
  script: npm run test:unit
  timeout: 2 minutes

# Kør ved PR
test:integration:
  script: npm run test:integration
  timeout: 10 minutes

# Kør før deployment
test:e2e:
  script: npm run test:e2e
  timeout: 30 minutes

Fejl hurtigt

Kør de hurtigste tests først. Hvis unit-tests fejler, så spring E2E-testene over.

Konklusion

En god teststrategi handler om tillid, ikke dækning. Du vil gerne:

  1. Fange fejl før produktion
  2. Muliggøre refaktorering uden frygt
  3. Dokumentere forventet adfærd
  4. Ikke bremse udviklingen

Fokusér din testindsats dér, hvor det betyder mest: forretningslogik, kritiske stier og integrationspunkter. Spring de tests over, der ikke tilfører værdi.

Den bedste testsuite er den, som dit team rent faktisk kører og har tillid til.

Alle artikler