Testing Grundlagen

Das Testen von Software ist ein fundamentaler Bestandteil der modernen Softwareentwicklung. Für JavaScript-Entwickler ist ein solides Verständnis der Testing-Grundlagen unerlässlich, um robuste und wartbare Anwendungen zu erstellen.

30.1 Was ist Software-Testing?

Software-Testing bezeichnet den Prozess der Überprüfung und Validierung, dass eine Anwendung oder ein System wie erwartet funktioniert. In JavaScript umfasst dies das Testen von Funktionen, Modulen, Komponenten und ganzen Anwendungen.

30.1.1 Warum ist Testing wichtig?

Fehlerfrüherkennung: Bugs werden bereits während der Entwicklung gefunden, nicht erst in der Produktion. Dies reduziert die Kosten und den Aufwand für Fehlerbehebungen erheblich.

Refactoring-Sicherheit: Tests fungieren als Sicherheitsnetz bei Code-Änderungen. Entwickler können Refactorings mit Vertrauen durchführen, da Tests sofort anzeigen, wenn etwas nicht mehr funktioniert.

Dokumentation: Gut geschriebene Tests dienen als lebende Dokumentation des Codes. Sie zeigen, wie Funktionen verwendet werden sollen und welches Verhalten erwartet wird.

Code-Qualität: Das Schreiben von Tests zwingt Entwickler dazu, über die Struktur und das Design ihres Codes nachzudenken, was zu besserem Code führt.

30.2 Arten von Tests

In der JavaScript-Entwicklung unterscheiden wir hauptsächlich zwischen drei Arten von Tests, die eine Testpyramide bilden:

30.2.1 Unit Tests

Unit Tests prüfen einzelne, isolierte Funktionen oder Methoden. Sie sind die Basis der Testpyramide und sollten den größten Anteil der Tests ausmachen.

// Beispiel einer einfachen Funktion
function addNumbers(a, b) {
  return a + b;
}

// Zugehöriger Unit Test (konzeptionell)
// Testet, ob 2 + 3 = 5 ergibt
// Testet, ob negative Zahlen korrekt addiert werden
// Testet, ob Fehlerbehandlung für ungültige Eingaben funktioniert

Unit Tests sind schnell ausführbar, einfach zu debuggen und bieten präzise Fehlerlokalisation. Sie testen eine Funktion in völliger Isolation von anderen Teilen des Systems.

30.2.2 Integration Tests

Integration Tests überprüfen das Zusammenspiel zwischen verschiedenen Modulen oder Komponenten. Sie testen die Schnittstellen und Interaktionen zwischen verschiedenen Teilen der Anwendung.

// Beispiel: Test der Interaktion zwischen Service und API
class UserService {
  constructor(apiClient) {
    this.apiClient = apiClient;
  }
  
  async getUser(id) {
    const response = await this.apiClient.get(`/users/${id}`);
    return response.data;
  }
}

// Integration Test würde prüfen:
// - Korrekte API-Aufrufe
// - Datenverarbeitung zwischen Service und API-Client
// - Fehlerbehandlung bei API-Fehlern

30.2.3 End-to-End Tests

End-to-End (E2E) Tests simulieren echte Benutzerinteraktionen und testen die gesamte Anwendung von der Benutzeroberfläche bis zur Datenbank. Sie sind am langsamsten, aber auch am realistischsten.

E2E Tests automatisieren Benutzerszenarien wie “Benutzer meldet sich an, navigiert zur Produktseite und fügt ein Produkt zum Warenkorb hinzu”.

30.3 Test-Driven Development (TDD)

Test-Driven Development ist eine Entwicklungsmethodik, bei der Tests vor dem eigentlichen Code geschrieben werden. Der TDD-Zyklus folgt dem “Red-Green-Refactor”-Muster:

// 1. Red: Fehlschlagender Test
function testCalculateTotal() {
  const items = [
    { price: 10, quantity: 2 },
    { price: 5, quantity: 3 }
  ];
  
  const expected = 35; // (10*2) + (5*3)
  const actual = calculateTotal(items);
  
  if (actual !== expected) {
    throw new Error(`Expected ${expected}, got ${actual}`);
  }
}

// 2. Green: Minimale Implementierung
function calculateTotal(items) {
  return items.reduce((sum, item) => sum + (item.price * item.quantity), 0);
}

// 3. Refactor: Code verbessern (falls nötig)

30.4 Testing-Konzepte und Terminologie

30.4.1 Assertions

Assertions sind Aussagen über den erwarteten Zustand des Systems. Sie bilden das Herzstück jedes Tests.

// Verschiedene Arten von Assertions
function assertEqual(actual, expected, message) {
  if (actual !== expected) {
    throw new Error(message || `Expected ${expected}, got ${actual}`);
  }
}

function assertTrue(condition, message) {
  if (!condition) {
    throw new Error(message || 'Expected condition to be true');
  }
}

function assertThrows(fn, expectedError, message) {
  try {
    fn();
    throw new Error(message || 'Expected function to throw an error');
  } catch (error) {
    if (error.constructor !== expectedError) {
      throw new Error(`Expected ${expectedError.name}, got ${error.constructor.name}`);
    }
  }
}

30.4.2 Test Fixtures

Test Fixtures sind vordefinierte Datensätze oder Systemzustände, die für Tests verwendet werden. Sie sorgen für konsistente und reproduzierbare Testbedingungen.

// Beispiel für Test Fixtures
const userFixtures = {
  validUser: {
    id: 1,
    name: 'John Doe',
    email: 'john@example.com',
    active: true
  },
  
  invalidUser: {
    id: null,
    name: '',
    email: 'invalid-email',
    active: false
  }
};

function testUserValidation() {
  const validResult = validateUser(userFixtures.validUser);
  assertTrue(validResult.isValid, 'Valid user should pass validation');
  
  const invalidResult = validateUser(userFixtures.invalidUser);
  assertTrue(!invalidResult.isValid, 'Invalid user should fail validation');
}

30.4.3 Mocking und Stubbing

Mocking und Stubbing sind Techniken zur Isolation von Code während des Testens. Sie ersetzen Abhängigkeiten mit kontrollierten Fake-Implementierungen.

// Einfaches Mock-Beispiel
function createMockApiClient() {
  return {
    get: function(url) {
      // Simuliert API-Response basierend auf URL
      if (url === '/users/1') {
        return Promise.resolve({
          data: { id: 1, name: 'Test User' }
        });
      }
      return Promise.reject(new Error('Not found'));
    }
  };
}

// Test mit Mock
async function testUserServiceWithMock() {
  const mockApi = createMockApiClient();
  const userService = new UserService(mockApi);
  
  const user = await userService.getUser(1);
  assertEqual(user.name, 'Test User', 'Should return mocked user');
}

30.5 Test-Organisation und Best Practices

30.5.1 Test-Struktur

Tests sollten eine klare, konsistente Struktur haben. Das AAA-Pattern (Arrange-Act-Assert) ist ein bewährter Ansatz:

function testUserCreation() {
  // Arrange: Vorbereitung der Testdaten
  const userData = {
    name: 'Jane Smith',
    email: 'jane@example.com'
  };
  const userRepository = new UserRepository();
  
  // Act: Ausführung der zu testenden Aktion
  const createdUser = userRepository.create(userData);
  
  // Assert: Überprüfung der Ergebnisse
  assertEqual(createdUser.name, userData.name, 'Name should match');
  assertEqual(createdUser.email, userData.email, 'Email should match');
  assertTrue(createdUser.id > 0, 'Should have valid ID');
}

30.5.2 Test-Isolation

Jeder Test sollte unabhängig von anderen Tests ausführbar sein. Tests dürfen sich nicht gegenseitig beeinflussen.

// Schlecht: Tests sind voneinander abhängig
let globalCounter = 0;

function testIncrement() {
  globalCounter++;
  assertEqual(globalCounter, 1, 'Should be 1');
}

function testDoubleIncrement() {
  globalCounter += 2; // Abhängig vom vorherigen Test!
  assertEqual(globalCounter, 3, 'Should be 3');
}

// Besser: Jeder Test ist isoliert
function testIncrement() {
  let counter = 0;
  counter++;
  assertEqual(counter, 1, 'Should be 1');
}

function testDoubleIncrement() {
  let counter = 0;
  counter += 2;
  assertEqual(counter, 2, 'Should be 2');
}

30.5.3 Aussagekräftige Testnamen

Testnamen sollten klar beschreiben, was getestet wird und welches Verhalten erwartet wird.

// Schlecht
function test1() { /* ... */ }
function testUser() { /* ... */ }

// Besser
function shouldReturnUserWhenValidIdProvided() { /* ... */ }
function shouldThrowErrorWhenUserNotFound() { /* ... */ }
function shouldCalculateCorrectTotalForMultipleItems() { /* ... */ }

30.6 Code Coverage

Code Coverage misst, welcher Anteil des Codes durch Tests abgedeckt ist. Es gibt verschiedene Arten von Coverage:

function processAge(age) {
  if (age < 0) {          // Branch 1
    throw new Error('Age cannot be negative');
  }
  
  if (age >= 18) {        // Branch 2
    return 'adult';
  } else {
    return 'minor';
  }
}

// Für 100% Branch Coverage benötigen wir Tests für:
// - Negative Zahlen (Fehlerfall)
// - Alter >= 18 (Erwachsener)
// - Alter < 18 (Minderjährig)

Während hohe Code Coverage erstrebenswert ist, garantiert sie nicht die Qualität der Tests. Ein Test, der Code ausführt, aber keine sinnvollen Assertions macht, trägt zur Coverage bei, aber nicht zur Testsicherheit.

30 Testing Grundlagen