Komkommer en scenario-overzicht

1. Inleiding

Komkommer is een BDD-testraamwerk (Behavioral Driven Development).

Het framework gebruiken om repetitieve scenario's te schrijven met verschillende permutaties van inputs / outputs kan behoorlijk tijdrovend, moeilijk te onderhouden en natuurlijk frustrerend zijn.

Cucumber kwam met een oplossing om deze inspanning te verminderen door gebruik te maken van het concept van Scenario-overzicht in combinatie met voorbeelden. In het onderstaande gedeelte zullen we proberen een voorbeeld te geven en kijken hoe we deze inspanning kunnen minimaliseren.

Als je meer wilt lezen over de aanpak en augurken-taal, bekijk dan dit artikel.

2. Ondersteuning voor komkommer toevoegen

Om ondersteuning voor Cucumber toe te voegen in een eenvoudig Maven-project, moeten we de volgende afhankelijkheden toevoegen:

 info.cukes cucumber-junit 1.2.5 test info.cukes cucumber-java 1.2.5 test org.hamcrest hamcrest-library 1.3 test 

Handige links naar afhankelijkheden van Maven Central: cucumber-junit, cucumber-java, hamcrest-library

Omdat dit testbibliotheken zijn, hoeven ze niet te worden geleverd met de daadwerkelijke inzetbare - en daarom zijn ze allemaal test bereik.

3. Een eenvoudig voorbeeld

Laten we zowel een opgeblazen manier als een beknopte manier demonstreren om aanbevolen bestanden te schrijven. Laten we eerst de logica definiëren waarvoor we een test willen schrijven:

Laten we eerst de logica definiëren waarvoor we een test willen schrijven:

openbare klasse Calculator {public int add (int a, int b) {return a + b; }}

4. Komkommertests definiëren

4.1. Een functiebestand definiëren

Functie: Rekenmachine Als gebruiker wil ik een rekenmachine gebruiken om getallen toe te voegen zodat ik mezelf niet hoef toe te voegen Scenario: voeg twee getallen toe -2 & 3 Gegeven dat ik een rekenmachine heb Wanneer ik -2 en 3 optel Dan zou het resultaat moeten zijn be 1 Scenario: voeg twee getallen 10 & 15 toe Gegeven dat ik een rekenmachine heb Wanneer ik 10 en 15 tel, dan zou het resultaat 25 moeten zijn 

Zoals hier te zien zijn, zijn er 2 verschillende combinaties van getallen getest om hier de optellogica te testen. Afgezien van cijfers zijn alle scenario's exact hetzelfde.

4.2. "Lijm" -code

Om deze scenario's te testen, is het essentieel om elke stap met bijbehorende code te definiëren, om een ​​statement te vertalen in een functioneel stuk code:

openbare klasse CalculatorRunSteps {privé int totaal; particuliere rekenmachine; @Before private void init () {totaal = -999; } @Given ("^ Ik heb een rekenmachine $") public void initializeCalculator () gooit Throwable {calculator = nieuwe rekenmachine (); } @When ("^ I add (-? \ d +) en (-? \ d +) $") public void testAdd (int num1, int num2) gooit Throwable {total = calculator.add (num1, num2); } @Then ("^ het resultaat moet (-? \ d +) $") zijn public void validateResult (int resultaat) gooit Throwable {Assert.assertThat (total, Matchers.equalTo (resultaat)); }}

4.3. Een Runner Class

Om functies en de lijmcode te integreren, kunnen we de JUnit-lopers gebruiken:

@RunWith (Cucumber.class) @CucumberOptions (features = {"classpath: features / calculator.feature"}, glue = {"com.baeldung.cucumber.calculator"}) openbare klasse CalculatorTest {}

5. Functies herschrijven met behulp van scenario-omtrekken

We zagen in paragraaf 4.1. hoe het definiëren van een feature-bestand een tijdrovende taak kan zijn en meer vatbaar voor fouten. Hetzelfde feature-bestand kan worden teruggebracht tot slechts enkele regels met behulp van de Scenario-overzicht:

Functie: Rekenmachine Als gebruiker wil ik een rekenmachine gebruiken om getallen toe te voegen Zodat ik mezelf niet hoef toe te voegen Scenario-overzicht: Voeg twee getallen toe & Gegeven dat ik een rekenmachine heb Wanneer ik optel en dan zou het resultaat moeten zijn Voorbeelden: | num1 | num2 | totaal | | -2 | 3 | 1 | | 10 | 15 | 25 | | 99 | -99 | 0 | | -1 | -10 | -11 |

Bij het vergelijken van een gewone Scenario-definitie met Scenario-overzichthoeven waarden niet langer hard te worden gecodeerd in stapdefinities. Waarden worden vervangen door parameters als in stap-definitie zelf.

Aan het einde van Scenario-overzicht worden waarden gedefinieerd in een door buizen gescheiden tabelindeling met Voorbeelden.

Een voorbeeld om te definiëren Voorbeelden wordt hieronder getoond:

Voorbeelden: | Parameter_Name1 | Parameter_Name2 | | Waarde-1 | Waarde-2 | | Waarde-X | Waarde-Y |

6. Conclusie

Met dit korte artikel hebben we laten zien hoe scenario's generiek van aard kunnen worden gemaakt. En verminder ook de inspanning bij het schrijven en onderhouden van deze scenario's.

De volledige broncode van dit artikel is te vinden op GitHub.


$config[zx-auto] not found$config[zx-overlay] not found