Antwoord.

Werken met dynamische wachttijden is een dringende kwestie in het gebied van UI-automatisering, vooral voor moderne webapplicaties, waar content vaak niet onmiddellijk verschijnt en verandert.

Achtergrond van de vraag In de vroege versies van automatisering werden harde wachttijden (sleep) gebruikt, wat tests te langzaam of flaky maakte als de applicaties langer dan normaal laadden. Dit werd relevant in het tijdperk van SPA en zware JS.

Probleem Het gebruik van statische vertragingen leidt tot onbetrouwbare tests en tijdsverlies: een autotest kan vertragen of toevallig "failen". Bovendien lijdt de schaalbaarheid en ondersteuning van tests.

Oplossing Gebruik dynamische (expliete) wachttijden: bijvoorbeeld WebDriverWait in Selenium, de functie waitFor in frameworks zoals Cypress en Playwright.

from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

wait = WebDriverWait(driver, 10)  # maximale wachtijd 10 seconden
wait.until(EC.visibility_of_element_located((By.ID, 'my-element')))

Belangrijke kenmerken:

Gebruik expliciete wachttijden alleen waar nodig
Geen wachttijden dupliceren voor hetzelfde evenement
Duidelijke definitie van de voorwaarden waar de wachttijd eindigt (zichtbaarheid/klikbaar/etc.)

Vragen met een valstrik.

Waarom zou je sleep gebruiken als er dynamische wachttijden zijn?

Het gebruik van time.sleep() is alleen gerechtvaardigd voor debuggen of in uiterste gevallen. In echte autotests is het beter altijd expliciete wachttijden te gebruiken.

Kan het gebruik van wachttijden flaky volledig uitsluiten?

Nee, als de voorwaarden voor de wachttijd ontoereikend zijn beschreven (bijvoorbeeld, we wachten op het verschijnen van een eigenschap, niet op de volledige gegevenslading), blijven flaky resultaten bestaan.

Is het mogelijk om één globale wachttijd voor alle tests te hebben?

Nee — de voorwaarden voor het verschijnen van elementen verschillen. Wachttijden moeten strikt worden toegepast op de stappen waar dit nodig is.

Typische fouten en anti-patronen

Het gebruik van sleep in plaats van wachttijden
Herhaalde wachttijden waar ze niet nodig zijn
Te lange time-outs, die het opsporen van echte fouten bemoeilijken

Voorbeeld uit het leven

Negatieve case

Alle autotests waren geschreven met sleep(2) tussen de "klik" en de controle. Na het vernieuwen van de pagina klaagden gebruikers over vertragingen, en de tests faalden soms door trage internetverbindingen.

Voordelen:

Zonder wachttijdcode zijn tests eenvoudig

Nadelen:

Tests duren lang
Flaky failures
Ze passen zich niet aan de werkelijke snelheid van de applicatie aan

Positieve case

We hebben expliciete wachttijden ingesteld voor het laden van blokken, de klik werd mogelijk na het verschijnen van de noodzakelijke elementen. We hebben sleep opgegeven, alle tests verlopen stabiel en snel.