Cómo pasar variables entre pasos de pepino-jvm

Solución:

Para compartir puntos en común entre los pasos, debe usar un mundo. En Java no es tan claro como en Ruby.

Citando al creador de Pepino.

El propósito de un “mundo” es doble:

1. Aislar el estado entre escenarios.

2. Comparta datos entre definiciones de pasos y enlaces dentro de un escenario.

Cómo se implementa esto es específico del idioma. Por ejemplo, en ruby, el implícito self La variable dentro de una definición de paso apunta al objeto World del escenario actual. Esta es por defecto una instancia de Object, pero puede ser cualquier cosa que desee si usa el gancho World.

En Java, tiene muchos objetos World (posiblemente conectados).

El equivalente del Mundo en Cucumber-Java es todos los objetos con anotaciones hook o stepdef. En otras palabras, cualquier clase con métodos anotados con @Before, @After, @Given, etc., se instanciará exactamente una vez para cada escenario.

Esto logra el primer objetivo. Para lograr el segundo objetivo, tiene dos enfoques:

a) Use una sola clase para todas sus definiciones de pasos y ganchos

b) Utilice varias clases divididas por responsabilidad [1] y usa la inyección de dependencia [2] para conectarlos entre sí.

La opción a) se descompone rápidamente porque su código de definición de pasos se vuelve un desastre. Es por eso que la gente tiende a usar b).

[1] https://cucumber.io/docs/gherkin/step-organization/

[2] PicoContainer, resorte, guice, soldadura, openEJB, aguja

Los módulos de inyección de dependencia disponibles son:

• pepino-picocontenedor
• pepino-guice
• pepino-openejb
• pepino-primavera
• pepino-soldadura
• pepino-aguja

Publicación original aquí https://groups.google.com/forum/#!topic/cukes/8ugcVreXP0Y.

Espero que esto ayude.

Está bien compartir datos entre pasos definidos dentro de una clase usando una variable de instancia. Si necesita compartir datos entre pasos en diferentes clases, debe mirar las integraciones DI (PicoContainer es el más simple).

En el ejemplo que muestra, preguntaría si es necesario mostrar “TEST” en el escenario. El hecho de que el usuario se llame TEST es un detalle incidental y hace que el escenario sea menos legible. ¿Por qué no generar un nombre aleatorio (o codificar algo) en Create_user_with_name ()?

Diría que hay razones para compartir información entre pasos, pero no creo que ese sea el caso en este escenario. Si propaga el nombre de usuario a través de los pasos de la prueba, la función no aclara realmente qué está sucediendo. Creo que es mejor decir específicamente en el escenario lo que se espera. Probablemente haría algo como esto:

Feature: Demo

  Scenario: Create user
    Given User creation form management
    When Create user with name "TEST"
    Then A user named "TEST" has been created

Entonces, sus pasos de prueba reales podrían verse así:

@When("^Create user with name "([^"]*)"$")
public void Create_user_with_name(String userName) throws Throwable {
   userService.createUser(userName);
}

@Then("^A user named "([^"]*)" has been created$")
public void User_is_created_successfully(String userName) throws Throwable {
   assertNotNull(userService.getUser(userName));
}

---

---

Utiliza Nuestro Buscador