Antwoord.

Achtergrond:

Oorspronkelijk werden geautomatiseerde tests vaak "in één keer" geschreven, zonder architecturale scheidingen: de logica voor controles en de uitvoeringsmechanismen waren door elkaar gehaald. Met de groei van projecten werd het duidelijk dat de mengeling van het framework en de testlogica een fragiele, moeilijk onderhoudbare codebasis creëert. Architecturale aanbevelingen voor het scheiden van verantwoordelijkheden ontstonden.

Probleem:

Als tests afhankelijk zijn van interne implementaties van het framework of logica voor interactie met de omgeving bevatten, dwingen eventuele wijzigingen tot het herschrijven van vele tests. Testcases zijn complex, code wordt gedupliceerd en de migratie naar een nieuw framework of platform is bemoeilijkt.

Oplossing:

Strikt scheiden:

Framework (baseline infrastructure): algemene mechanica voor het starten van tests, logging, foutafhandeling, rapporten, basis voor hulpkclasses (bijvoorbeeld, drivers, adapters en utilities).
Testlogica (test cases): specifieke scenario's die de betekenis van de test uitdrukken, gebruiken alleen publieke API's van het framework.

Belangrijke kenmerken:

Gemak van onderhoud dankzij isolatie van platformveranderingen
Mogelijkheid tot hergebruik van testlogica
Vermindering van overbodigheid en code duplicatie

Misleidende vragen.

Is het toegestaan om teststappen rechtstreeks in tests te schrijven als er maar een paar zijn?

Dat is niet aan te raden. Zelfs korte tests kunnen groeien, en de afwezigheid van lagen leidt snel tot chaos.

Moeten testscenario's weten over de mechanica van het starten (bijvoorbeeld wanneer de driver te initialiseren)?

Nee. Alle details van de infrastructuur moeten verborgen blijven in de laag van het framework.

Is het normaal om parameters van tests hardcoded in de cases te zetten (bijvoorbeeld, url, credentials)?

Nee. Testparameters moeten worden geconfigureerd via de instellingen van het framework en de omgeving.

Typische fouten en anti-patronen

Plaatsing van statuscontroles binnen de methoden van het framework, en niet in de tests
Gebruik van privé-methoden van het framework in tests
Duplicatie van hulpfuncties in tests
Hardcoding van parameters

Voorbeeld uit de praktijk

Negatieve case

In het project roepen tests rechtstreeks de methoden van de Selenium-driver aan, waarbij in elke test een verbinding met WebDriver wordt herhaald. Elke test parseert zelf de configuratie.

Voordelen:

Je kunt snel beginnen met het schrijven van autotests zonder architectuur

Nadelen:

Wijzigingen in de driver of opstartparameters leiden tot massale aanpassingen
Duplicerende code in alle tests
Moeilijk te schalen en te onderhouden project

Positieve case

Tests gebruiken de basisabstracties van het framework: algemene initialisatie en teardown, doorlopende overdracht van parameters via de configurator, testlogica wordt uitgedrukt via hoog-niveau methoden.