Wie man gute Unit-Tests schreibt: Grundlagen

Wer in der Softwareentwicklung tätig ist, weiß: Gute Unit-Tests sind der Schlüssel zu robustem Code. Doch was zeichnet einen guten Unit-Test aus? In diesem Artikel tauchen wir in die Grundlagen ein, die jeder Entwickler kennen sollte. Lass uns die Essenz des Schreibens effizienter Unit-Tests erkunden und umsetzen.

Grundlagen des Schreibens guter Unit-Tests

Unit-Tests sind ein fundamentaler Bestandteil der Softwareentwicklung, die sich auf das Testen isolierter Codeeinheiten konzentrieren. Diese Tests stellen sicher, dass einzelne Komponenten wie erwartet funktionieren.

Die Entwicklung effektiver Unit-Tests basiert auf dem AAA-Muster (Arrange, Act, Assert), das eine klare Struktur vorgibt und die Lesbarkeit verbessert. Dieses Muster hilft dabei, Tests systematisch aufzubauen und macht sie wartbar.

Ein gut geschriebener Unit-Test konzentriert sich auf eine spezifische Funktionalität und vermeidet externe Abhängigkeiten durch den Einsatz von Mocks und Stubs. Dies gewährleistet, dass Fehler präzise lokalisiert werden können.

Die folgende Tabelle zeigt die wichtigsten Komponenten des AAA-Musters:

Für die praktische Implementierung von Unit-Tests empfehlen sich vier zentrale Schritte:

• Identifizierung der zu testenden Komponente und ihrer Abhängigkeiten
• Erstellung von Testfällen für den Normalfall und Randbedingungen
• Implementierung der Tests nach dem AAA-Muster
• Durchführung und Validierung der Tests in der Entwicklungsumgebung

Weitere praktische Tipps zur effektiven Nutzung von Unit-Tests findest du im Artikel Effektive Nutzung von Unit-Tests.

Testgesteuerte Entwicklung (TDD) und ihre Rolle bei Unit-Tests

Die testgetriebene Entwicklung ist ein methodischer Ansatz, bei dem du Tests schreibst, bevor du den eigentlichen Code implementierst. Dieser Prozess hilft dir dabei, die Anforderungen präzise zu definieren und qualitativ hochwertige Software zu entwickeln.

Der TDD-Zyklus folgt einem strukturierten Ablauf, der die Entwicklung systematisch gestaltet. Dabei wird nach dem „Red-Green-Refactor“ Prinzip gearbeitet, das die Qualität des Codes von Anfang an sicherstellt.

Hier ein Beispiel in Apex, das den TDD-Ansatz demonstriert:

// ITERATION 1: Start with a basic test
@isTest
private class DiscountCalculatorTest {
    @isTest
    static void calculateDiscount_StandardCustomer_NoDiscount() {
        // Arrange
        DiscountCalculator calculator = new DiscountCalculator();
        
        // Act
        Decimal discount = calculator.calculateDiscount(100.00, 'STANDARD');
        
        // Assert
        System.assertEquals(0, discount, 'Standard customers should get no discount');
    }
}

// Initial implementation to make the test pass
public class DiscountCalculator {
    public Decimal calculateDiscount(Decimal amount, String customerType) {
        return 0;
    }
}

// ITERATION 2: Add test for premium customers
@isTest
private class DiscountCalculatorTest {
    @isTest
    static void calculateDiscount_StandardCustomer_NoDiscount() {
        DiscountCalculator calculator = new DiscountCalculator();
        Decimal discount = calculator.calculateDiscount(100.00, 'STANDARD');
        System.assertEquals(0, discount, 'Standard customers should get no discount');
    }
    
    @isTest
    static void calculateDiscount_PremiumCustomer_TenPercentDiscount() {
        // Arrange
        DiscountCalculator calculator = new DiscountCalculator();
        
        // Act
        Decimal discount = calculator.calculateDiscount(100.00, 'PREMIUM');
        
        // Assert
        System.assertEquals(10, discount, 'Premium customers should get 10% discount');
    }
}

// Updated implementation
public class DiscountCalculator {
    public Decimal calculateDiscount(Decimal amount, String customerType) {
        if (customerType == 'PREMIUM') {
            return amount * 0.10;
        }
        return 0;
    }
}

// ITERATION 3: Refactor and add validation
@isTest
private class DiscountCalculatorTest {
    private static DiscountCalculator calculator;
    
    @TestSetup
    static void setup() {
        calculator = new DiscountCalculator();
    }
    
    @isTest
    static void calculateDiscount_StandardCustomer_NoDiscount() {
        Decimal discount = calculator.calculateDiscount(100.00, 'STANDARD');
        System.assertEquals(0, discount, 'Standard customers should get no discount');
    }
    
    @isTest
    static void calculateDiscount_PremiumCustomer_TenPercentDiscount() {
        Decimal discount = calculator.calculateDiscount(100.00, 'PREMIUM');
        System.assertEquals(10, discount, 'Premium customers should get 10% discount');
    }
    
    @isTest
    static void calculateDiscount_NegativeAmount_ThrowsException() {
        try {
            calculator.calculateDiscount(-100.00, 'STANDARD');
            System.assert(false, 'Expected exception was not thrown');
        } catch (DiscountCalculator.DiscountCalculatorException e) {
            System.assertEquals('Amount cannot be negative', e.getMessage());
        }
    }
    
    @isTest
    static void calculateDiscount_InvalidCustomerType_ThrowsException() {
        try {
            calculator.calculateDiscount(100.00, 'INVALID');
            System.assert(false, 'Expected exception was not thrown');
        } catch (DiscountCalculator.DiscountCalculatorException e) {
            System.assertEquals('Invalid customer type', e.getMessage());
        }
    }
}

// Final refactored implementation
public class DiscountCalculator {
    private static final Set<String> VALID_CUSTOMER_TYPES = new Set<String>{'STANDARD', 'PREMIUM'};
    private static final Map<String, Decimal> DISCOUNT_RATES = new Map<String, Decimal>{
        'STANDARD' => 0,
        'PREMIUM' => 0.10
    };
    
    public Decimal calculateDiscount(Decimal amount, String customerType) {
        validateInput(amount, customerType);
        return amount * DISCOUNT_RATES.get(customerType);
    }
    
    private void validateInput(Decimal amount, String customerType) {
        if (amount < 0) {
            throw new DiscountCalculatorException('Amount cannot be negative');
        }
        
        if (!VALID_CUSTOMER_TYPES.contains(customerType)) {
            throw new DiscountCalculatorException('Invalid customer type');
        }
    }
    
    public class DiscountCalculatorException extends Exception {}
}

// ITERATION 4: Add test for bulk operations
@isTest
private class DiscountCalculatorTest {
    // ... previous test methods ...
    
    @isTest
    static void calculateBulkDiscounts_MultipleCustomers_CorrectDiscounts() {
        // Arrange
        List<Decimal> amounts = new List<Decimal>{100.00, 200.00, 300.00};
        List<String> customerTypes = new List<String>{'STANDARD', 'PREMIUM', 'PREMIUM'};
        
        // Act
        List<Decimal> discounts = calculator.calculateBulkDiscounts(amounts, customerTypes);
        
        // Assert
        System.assertEquals(3, discounts.size(), 'Should return discount for each customer');
        System.assertEquals(0, discounts[0], 'Standard customer should get no discount');
        System.assertEquals(20, discounts[1], 'Premium customer should get 10% of 200');
        System.assertEquals(30, discounts[2], 'Premium customer should get 10% of 300');
    }
}

// Add bulk calculation method
public class DiscountCalculator {
    // ... previous code ...
    
    public List<Decimal> calculateBulkDiscounts(List<Decimal> amounts, List<String> customerTypes) {
        if (amounts.size() != customerTypes.size()) {
            throw new DiscountCalculatorException('Amount and customer type lists must be same size');
        }
        
        List<Decimal> discounts = new List<Decimal>();
        for (Integer i = 0; i < amounts.size(); i++) {
            discounts.add(calculateDiscount(amounts[i], customerTypes[i]));
        }
        return discounts;
    }
}

Für eine vertiefte Auseinandersetzung mit TDD-Praktiken empfehlen wir den Artikel Test-Driven Development in der Praxis.

Mocking und Code-Isolation in Unit-Tests

Das Isolieren von Code durch Mocking ist ein essentieller Bestandteil effektiver Unit-Tests. Diese Technik ermöglicht es, Komponenten unabhängig von ihren externen Abhängigkeiten zu testen und präzise Ergebnisse zu erhalten.

Mocks simulieren das Verhalten von realen Objekten und Systemen, wodurch du komplexe Abhängigkeiten wie Datenbanken oder Netzwerkaufrufe kontrolliert nachbilden kannst. Dies führt zu schnelleren und zuverlässigeren Tests.

Die Implementierung von Mocks erfolgt über spezialisierte Bibliotheken, die für verschiedene Programmiersprachen verfügbar sind. Hier die wichtigsten Optionen:

• Mockito für Java – Bietet eine intuitive API und umfangreiche Mocking-Funktionen
• Jest für JavaScript – Integriert Mocking-Funktionalitäten direkt in das Test-Framework
• Moq für .NET – Ermöglicht elegantes Mocking mit einer fluent API

Ein praktisches Beispiel für Mockito in Apex:

// Class to be tested
public class AccountService {
    private HttpCalloutService httpService;
    
    public AccountService(HttpCalloutService httpService) {
        this.httpService = httpService;
    }
    
    public Map<String, Object> getAccountDetails(String accountId) {
        String endpoint = 'https://api.example.com/accounts/' + accountId;
        HttpResponse response = httpService.get(endpoint);
        
        if (response.getStatusCode() == 200) {
            return (Map<String, Object>)JSON.deserializeUntyped(response.getBody());
        }
        throw new AccountServiceException('Failed to fetch account details');
    }
    
    public class AccountServiceException extends Exception {}
}

// Interface for HTTP service
public interface HttpCalloutService {
    HttpResponse get(String endpoint);
}

// Test class using Mockito
@isTest
private class AccountServiceTest {
    private static final String MOCK_ACCOUNT_ID = '001xx000003DGb9AAG';
    private static HttpCalloutService mockHttpService = mock(HttpCalloutService.class);
    private static AccountService accountService = new AccountService(mockHttpService);
    
    @isTest
    static void testGetAccountDetails_Success() {
        // Arrange
        HttpResponse mockResponse = new HttpResponse();
        mockResponse.setStatusCode(200);
        mockResponse.setBody('{"id": "' + MOCK_ACCOUNT_ID + '", "name": "Test Account"}');
        
        when(mockHttpService.get('https://api.example.com/accounts/' + MOCK_ACCOUNT_ID))
            .thenReturn(mockResponse);
        
        // Act
        Map<String, Object> result = accountService.getAccountDetails(MOCK_ACCOUNT_ID);
        
        // Assert
        System.assertEquals(MOCK_ACCOUNT_ID, result.get('id'), 'Account ID should match');
        System.assertEquals('Test Account', result.get('name'), 'Account name should match');
        
        // Verify the mock was called exactly once
        verify(mockHttpService, times(1)).get(anyString());
    }
    
    @isTest
    static void testGetAccountDetails_Error() {
        // Arrange
        HttpResponse mockResponse = new HttpResponse();
        mockResponse.setStatusCode(404);
        mockResponse.setBody('{"error": "Account not found"}');
        
        when(mockHttpService.get(anyString()))
            .thenReturn(mockResponse);
        
        // Act & Assert
        try {
            accountService.getAccountDetails(MOCK_ACCOUNT_ID);
            System.assert(false, 'Expected exception was not thrown');
        } catch (AccountService.AccountServiceException e) {
            System.assertEquals('Failed to fetch account details', e.getMessage(), 
                'Exception message should match');
        }
        
        // Verify the mock was called
        verify(mockHttpService).get(anyString());
    }
    
    @isTest
    static void testGetAccountDetails_MultipleResponses() {
        // Arrange
        HttpResponse successResponse = new HttpResponse();
        successResponse.setStatusCode(200);
        successResponse.setBody('{"id": "' + MOCK_ACCOUNT_ID + '", "name": "Test Account"}');
        
        HttpResponse errorResponse = new HttpResponse();
        errorResponse.setStatusCode(500);
        
        // Configure mock to return different responses on consecutive calls
        when(mockHttpService.get(anyString()))
            .thenReturn(successResponse)
            .thenReturn(errorResponse);
        
        // Act & Assert - First call should succeed
        Map<String, Object> result = accountService.getAccountDetails(MOCK_ACCOUNT_ID);
        System.assertEquals(MOCK_ACCOUNT_ID, result.get('id'), 'First call should return success');
        
        // Second call should fail
        try {
            accountService.getAccountDetails(MOCK_ACCOUNT_ID);
            System.assert(false, 'Expected exception was not thrown on second call');
        } catch (AccountService.AccountServiceException e) {
            System.assertEquals('Failed to fetch account details', e.getMessage());
        }
        
        // Verify mock was called exactly twice
        verify(mockHttpService, times(2)).get(anyString());
    }
}

Für detaillierte Einblicke in fortgeschrittene Mocking-Strategien empfehlen wir den Artikel Fortgeschrittene Mocking-Techniken.

Überprüfung der Codeabdeckung und Performance in Unit-Tests

Die Codeabdeckung ist ein wichtiger Indikator für die Qualität deiner Unit-Tests. Sie zeigt an, welcher Anteil des Codes durch Tests abgedeckt wird und hilft dabei, potenzielle Lücken in der Testabdeckung zu identifizieren.

Entgegen der häufigen Annahme ist eine 100-prozentige Codeabdeckung nicht immer erforderlich oder sinnvoll. Der Fokus sollte auf der Testung geschäftskritischer Funktionen und komplexer Logik liegen.

Die Performance deiner Unit-Tests spielt eine entscheidende Rolle für die Entwicklungsgeschwindigkeit. Langsame Tests können den Entwicklungsprozess behindern und die Motivation zum regelmäßigen Testen senken.

Für die effiziente Ausführung von Unit-Tests empfehlen sich folgende Praktiken:

• Parallele Testausführung für schnellere Ergebnisse
• Vermeidung unnötiger Datenbankzugriffe durch Mocking
• Regelmäßige Bereinigung von Test-Ressourcen
• Fokussierung auf relevante Testfälle statt Vollständigkeit

Weitere Details zur Performance-Optimierung findest du im Artikel Testautomatisierungstechniken bei Salesforce.

Do’s and Don’ts beim Schreiben von Unit-Tests

Die Entwicklung effektiver Unit-Tests erfordert ein tiefes Verständnis bewährter Praktiken. Ein strukturierter Ansatz hilft dabei, häufige Fallstricke zu vermeiden und qualitativ hochwertige Tests zu erstellen.

Die folgenden Do’s und Don’ts basieren auf praktischen Erfahrungen und etablierten Standards der Softwareentwicklung. Sie dienen als Leitfaden für die Erstellung robuster und wartbarer Tests.

Bei der Testinitialisierung ist es wichtig, einen klaren und konsistenten Aufbau zu befolgen. Dies verbessert die Lesbarkeit und erleichtert die Wartung der Tests.

Zur Vermeidung häufiger Fehler empfehlen sich diese praktischen Maßnahmen:

• Testdaten in separaten Fixtures oder Factories verwalten
• Mock-Objekte für externe Abhängigkeiten verwenden
• Assertions präzise und aussagekräftig formulieren
• Tests regelmäßig im CI/CD-Pipeline ausführen

Die Verifizierung der Testergebnisse sollte systematisch erfolgen. Jeder Test muss eindeutige Kriterien für Erfolg oder Misserfolg definieren.

Weitere detaillierte Informationen findest du im Artikel Unit-Test-Optimierung: Häufige Fehler vermeiden.

Fazit

Effektive Unit-Tests bilden das Rückgrat solider Softwareentwicklung und erhöhen die Codequalität.
Die Konzentration auf isolierte Code-Ausschnitte mithilfe von Mocks und Stubs, das Befolgen des Arrange, Act, Assert-Musters sowie die Anwendung von TDD machen Tests klarer und leistungsfähiger.

Für eine tiefgehende Codeabdeckung und Performance-Optimierung sind regelmäßige Testläufe, auch in CI-Umgebungen, unverzichtbar.
Fehlervermeidung und Best Practices helfen, wertvolle Ressourcen zu sparen und die Codeverifizierung zu stärken.

Wer mehr über wie man gute Unit-Tests schreibt wissen möchte, kann sich gerne an uns wenden, um maßgeschneiderte Lösungsansätze für spezifische Unternehmensherausforderungen zu erhalten.

FAQ