Concombre et aperçu du scénario

Concombre et aperçu du scénario

1. introduction

Cucumber est un framework de test BDD (Behavioral Driven Development).

Utiliser le cadreto write repetitive scenarios avec différentes permutations d'entrées / sorties peut être assez long, difficile à maintenir et bien sûr frustrant.

Le concombre est venu avec une solution pour réduire cet effort en utilisant le concept deScenario Outline coupled with Examples. Dans la section ci-dessous, nous allons essayer de prendre un exemple et de voir comment minimiser cet effort.

Si vous voulez en savoir plus sur l'approche et le langage Gherkin, jetez un œil àthis article.

2. Ajout du support de concombre

Pour ajouter la prise en charge de Cucumber dans un projet Maven simple, nous devrons ajouter les dépendances suivantes:


    info.cukes
    cucumber-junit
    1.2.5
    test


    info.cukes
    cucumber-java
    1.2.5
    test


    org.hamcrest
    hamcrest-library
    1.3
    test

Liens utiles vers les dépendances de Maven Central:cucumber-junit,cucumber-java,hamcrest-library

Comme il s'agit de bibliothèques de test, elles n'ont pas besoin d'être livrées avec le déploiement réel - c'est pourquoi elles sont toutes couvertes partest.

3. Un exemple simple

Voyons à la fois une manière volumineuse et une manière concise d'écrire des fichiers en vedette. Définissons d'abord la logique pour laquelle nous voulons écrire un test:

Définissons d'abord la logique pour laquelle nous voulons écrire un test:

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

4. Définition des tests de concombre

4.1. Définition d'un fichier d'entités

Feature: Calculator
  As a user
  I want to use a calculator to add numbers
  So that I don't need to add myself

  Scenario: Add two numbers -2 & 3
    Given I have a calculator
    When I add -2 and 3
    Then the result should be 1

  Scenario: Add two numbers 10 & 15
    Given I have a calculator
    When I add 10 and 15
    Then the result should be 25

Comme on le voit ici, 2 combinaisons de nombres différentes ont été mises à l’épreuve pour tester la logique d’addition. Hormis les chiffres, tous les scénarios sont exactement les mêmes.

4.2. Code «Glue»

Afin de tester ces scénarios, il est essentiel de définir chaque étape avec le code correspondant, afin de traduire une instruction en un morceau de code fonctionnel:

public class CalculatorRunSteps {

    private int total;

    private Calculator calculator;

    @Before
    private void init() {
        total = -999;
    }

    @Given("^I have a calculator$")
    public void initializeCalculator() throws Throwable {
        calculator = new Calculator();
    }

    @When("^I add (-?\\d+) and (-?\\d+)$")
    public void testAdd(int num1, int num2) throws Throwable {
        total = calculator.add(num1, num2);
    }

    @Then("^the result should be (-?\\d+)$")
    public void validateResult(int result) throws Throwable {
        Assert.assertThat(total, Matchers.equalTo(result));
    }
}

4.3. Une classe de coureur

Pour intégrer les fonctionnalités et le code de liaison, nous pouvons utiliser les coureurs JUnit:

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

5. Réécriture de fonctionnalités à l'aide de contours de scénario

Nous avons vu à la section 4.1. comment définir un fichier de caractéristiques peut être une tâche fastidieuse et plus sujette aux erreurs. Le même fichier d'entités peut être réduit à quelques lignes à l'aide desScenario Outline:

Feature: Calculator
  As a user
  I want to use a calculator to add numbers
  So that I don't need to add myself

  Scenario Outline: Add two numbers  & 
    Given I have a calculator
    When I add  and 
    Then the result should be 

  Examples:
    | num1 | num2 | total |
    | -2 | 3 | 1 |
    | 10 | 15 | 25 |
    | 99 | -99 | 0 |
    | -1 | -10 | -11 |

Lors de la comparaison d'unScenario Definition régulier avec unScenario Outline, les valeurs n'ont plus besoin d'être codées en dur dans les définitions d'étape. Les valeurs sont remplacées par des paramètres comme<parameter_name> dans la définition d'étape elle-même.

À la fin de la structure du scénario, les valeurs sont définies dans un format de table délimité par des barres verticales à l'aide deExamples.

Un exemple pour définirExamples est présenté ci-dessous:

Examples:
  | Parameter_Name1 | Parameter_Name2 |
  | Value-1 | Value-2 |
  | Value-X | Value-Y |

6. Conclusion

Avec cet article rapide, nous avons montré comment les scénarios peuvent être généralisés par nature. Et réduisez également les efforts d'écriture et de maintenance de ces scénarios.

Le code source complet de cet article est disponibleover on GitHub.