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.