Was ist ein warmer Kunde?

Ein "warmer" Client im Testkontext ist ein Client (z.B. ein Browserfenster, eine mobile Anwendung), der gestartet und für Tests konfiguriert wurde, aber noch nicht direkt am Testszenario teilgenommen hat. Im Wesentlichen ist es eine einsatzbereite Testumgebung.

Unterschiede zum "kalten" Client:

• Start und Initialisierung: Der "warme" Client ist bereits gestartet, hat die notwendigen Ressourcen (Seiten, Daten) geladen und möglicherweise eine vorherige Authentifizierung durchlaufen. Der "kalte" Client erfordert einen vollständigen Start und eine Initialisierung für jeden Test oder Testsatz.
• Zustand: Der "warme" Client behält einen gewissen Zustand zwischen Tests (z.B. Autorisierungstoken, zwischengespeicherte Daten), was schnellere Folge-Tests ermöglicht. Der "kalte" Client beginnt in der Regel bei Null.
• Ausführungszeit: Die Verwendung "warmer" Clients kann die Ausführungszeit der Testszenarien erheblich verkürzen, da langwierige Initialisierungsoperationen vermieden werden.

Vorteile der Verwendung eines "warmen" Clients:

• Zeiteinsparung: Verkürzung der Startzeit des Browsers/der Anwendung und des Ladens der Startseite/des Startbildschirms.
• Testbeschleunigung: Tests, die eine Authentifizierung erfordern, laufen schneller, da der Login-Prozess nicht bei jedem Test wiederholt werden muss.
• Effizienz: Besonders bei großen Regressionstestsätze relevant.

Nachteile:

• Potenzielle Zustandsbeeinflussung: Der Zustand, der vom vorherigen Test verbleibt, kann das Ergebnis des aktuellen Tests beeinflussen (Flags, Cookies, Local Storage). Es ist eine sorgfältige Zustandsverwaltung erforderlich.
• Komplexere Einrichtung: Es muss Logik entwickelt werden, um den "warmen" Zustand zu pflegen und nach jedem Test zu bereinigen, um Isolation zu gewährleisten.
• Höherer Ressourcenverbrauch: Ein ständig laufender Client kann mehr Systemressourcen verbrauchen.

Beispiel in automatisierten Tests (Selenium WebDriver):

Anstatt für jeden Test eine neue Driver-Instanz zu erstellen:

// "Kalter" Ansatz
@Test
public void testFeatureA() {
    WebDriver driver = new ChromeDriver(); // Neuer Browserstart
    //... Test-Szenario
    driver.quit();
}

@Test
public void testFeatureB() {
    WebDriver driver = new ChromeDriver(); // Neuer Browserstart
    //... Test-Szenario
    driver.quit();
}

Es wird eine einzelne Driver-Instanz verwendet, die zwischen den Tests wiederverwendet wird (ungefähre Logik):

// "Warmer" Ansatz (mit BeforeAll/AfterAll oder ähnlichen Hooks/Annotations)
private static WebDriver driver;

@BeforeAll // Wird einmal vor allen Tests in der Klasse ausgeführt
public static void setup() {
    driver = new ChromeDriver();
    driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));
    driver.get("https://your-app.com/login");
    // Authentifizierungslogik
}

@AfterAll // Wird einmal nach allen Tests in der Klasse ausgeführt
public static void teardown() {
    if (driver != null) {
        driver.quit();
    }
}

@BeforeEach // Wird vor jedem Test ausgeführt
public void prepareTest() {
    // Logik zum Zustand-Reset, falls notwendig (z.B. Cookies löschen, auf Startseite navigieren)
    driver.manage().deleteAllCookies();
    driver.navigate().to("https://your-app.com/dashboard");
}

@Test
public void testFeatureA() {
    // Bereits gestarteten und authentifizierten Driver verwenden
    // ... Test-Szenario
}

@Test
public void testFeatureB() {
    // Dieselben Driver verwenden
    // ... Test-Szenario
}

Dies vermeidet das wiederholte Starten des Browsers und das erneute Einloggen für jeden Test.