testing - cucumber python

Desarrollo impulsado por comportamiento para java: ¿qué marco utilizar?

Question

Para los proyectos en curso y para mejorar nuestro proceso de desarrollo consideramos la adopción de TDD como filosofía de desarrollo. Mientras investigaba sobre las mejores prácticas y sobre cómo "vender" el nuevo enfoque a mis colegas / desarrolladores, me encontré con BDD y me pareció aún más apropiado para lo que necesitaríamos y de alguna manera sería la próxima versión de TDD. El problema es que hasta ahora probé solo la JBehave desarrollada por Dan North , JBehave y no puedo decir que estoy sorprendido.

La configuración me parece engorrosa y no pude encontrar la documentación adecuada para ello. Por otro lado, probé también spock la herramienta Groovy y hasta ahora me gusta.

P: ¿hay alguna herramienta adecuada para ser utilizada para BDD?
P: ¿usaría spock en su lugar y se ocuparía de la introducción de otro idioma?

Answer 1

A menos que el propietario de su producto / qa / cliente necesite poder leer las pruebas, use spock . Es una herramienta muy simple, pero mejora la legibilidad de las pruebas. Gracias a sus potentes funciones, no necesitas Mockito, Hamcrest ni AssertJ. Y tiene excelentes pruebas parametrizadas. De hecho, es "solo" una mejor JUnit: una herramienta general para la ejecución automatizada de tareas simples, ya sean pruebas unitarias, pruebas de integración o pruebas de aceptación.

¿Temes a Groovy? ¿Por qué? Es muy similar a Java. Cuanto más lo aprenda, más expresivo y más corto es su código. Sus pruebas serán más cortas y más legibles. Groovy es la droga de entrada al mejor lado de JVM.

¿No te gustan los lenguajes dinámicos? Bueno, son las pruebas , y las pruebas son ejecutadas por el servidor de CI después de cada confirmación , ¿verdad? Si tu código se rompe, lo sabrás luego de unos minutos. ¿No tiene el servidor de CI o no está ejecutando pruebas regularmente? Entonces no se moleste en elegir un marco de pruebas y vaya a arreglar su proceso. Las pruebas rotas son inútiles y si no realiza las pruebas regularmente, se romperán pronto.

Ve con JBehave / Cucumber si lo necesitas; De lo contrario, use Spock.

Answer 2

Buena discusión! No conocía a JGiven, pero echaré un vistazo.

Además, soy el autor de COLA Tests , un nuevo framework que admite la sintaxis de pepinillo completo (precisamente lo mismo que Cucumber), es realmente fácil de configurar, especialmente cuando se compara con JBehave y no requiere JUnit runner.

Básicamente solo use las libs a las que ya está acostumbrado.

Aquí hay un ejemplo de Spring Controller Test (las historias se pueden cargar desde un archivo):

@RunWith(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
@ContextConfiguration(classes = { WebAppContext.class })
public class HelloWorldControllerTest extends BaseColaTest {

    private final String stories =
        "Feature: Introduce REST endpoint/n"
            + "Scenario: Should say hello/n"
            + "Given a web endpoint/n"
            + "When hit by a get request/n"
            + "Then the HTTP status will be OK/n"
            + "And the body will say hello world";

    @Resource
    private WebApplicationContext webApplicationContext;
    private MockMvc mockMvc;
    private ResultActions result;

    @Given("a web endpoint")
    public void given() {
        mockMvc = MockMvcBuilders.webAppContextSetup(webApplicationContext).build();
    }

    @When("hit by a get request")
    public void when() throws Exception {
        result = mockMvc.perform(get("/helloWorld"));
    }

    @Then("the HTTP status will be OK")
    public void thenOk() throws Exception {
        result.andExpect(status().isOk());
    }

    @Then("the body will say hello world")
    public void thenHello() throws Exception {
        result.andExpect(content().string("Hello World!"));
    }
}

Answer 3

Como autor de JGiven , tengo que estar en desacuerdo con Sody en cuanto a que Java no tiene suficiente flexibilidad para la creación de DSL. En JGiven, las pruebas de BDD se ven de la siguiente manera:

@Test
public void users_can_login {
    given()
       .a_registered_user()
       .and().the_login_page_is_shown();

    when()
       .the_user_enters_correct_credentials()
       .and().the_login_button_is_pressed();

    then()
       .the_welcome_page_is_shown();
}

JGiven se usa junto con JUnit o TestNg y usted escribe sus pruebas en Java simple.

Answer 4

Dale una Ginkgo4j a Ginkgo4j . Utiliza los lamda de Java 8 para reflejar el enfoque utilizado por Ruby''s RSpec y Go''s Ginkgo.

Esta biblioteca le permite crear pruebas expresivas y ricas en contenido.

`` `

package com.github.paulcwarren.ginkgo4j.examples;

import static com.github.paulcwarren.ginkgo4j.Ginkgo4jDSL.*;
import static org.hamcrest.CoreMatchers.is;
import static org.hamcrest.MatcherAssert.assertThat;

import org.junit.runner.RunWith;

import com.github.paulcwarren.ginkgo4j.Ginkgo4jRunner;

@RunWith(Ginkgo4jRunner.class)
public class BookTests {
    private Book longBook;
    private Book shortBook;
    {
        Describe("Book", () -> {
            BeforeEach(() -> {
                longBook = new Book("Les Miserables", "Victor Hugo", 1488);
                shortBook = new Book("Fox In Socks", "Dr. Seuss", 24);
       });

       Context("Categorizing book length", () -> {
           Context("With more than 300 pages", () -> {
               It("should be a novel", () -> {
                   assertThat(longBook.categoryByLength(), is("NOVEL"));
               });
           });

           Context("With fewer than 300 pages", () -> {
               It("should be a short story", () -> {
                   assertThat(shortBook.categoryByLength(), is("NOVELLA"));
              });
           });
       });
       });
     }
}

`` `

También es compatible con Spring.

(Divulgación completa. Soy el autor de esta biblioteca).

Answer 5

Otra alternativa sería Spectrum: consulte https://github.com/greghaskins/spectrum

Spectrum admite la sintaxis RSpec / Mocha y en su próxima versión también admitirá la sintaxis Gherkin, junto con la integración de la regla JUnit (por lo que interopera con Mockito, Spring, etc. a través de los miembros @Rule y @ClassRule ).

Divulgación completa: soy colaborador de este proyecto de SO

Ejemplo:

@RunWith(Spectrum.class)
public class TestSomething {{
    Supplier<Something> freshTestObject = let(Something::new);

    describe("The component", () -> {
        it("is tested by specs", () -> {
            // the "let` above gives us a new instance of the object
            // in each spec
            freshTestObject.get().doSomething();

            // using your favourite assertion framework
            assertThat(something.get().getSomething()).isEqualTo(42);
        });
    });
}}

Spectrum genera un resultado de prueba jerárquica en la consola JUnit. Su punto fuerte es mezclar la implementación de Java de la ejecución de la especificación con la definición de la especificación; esto puede ser más directo que los marcos que dependen de los archivos de características y el código de pegamento para analizarlos, especialmente si es necesario pasar los resultados de un solo paso de la prueba a otro.

Spectrum pretende ser políglota, por lo que debería resultar familiar para los usuarios de varios frameworks existentes.

Answer 6

Behavior Driven Development es solo una técnica que se puede usar sin herramientas. Puede simplemente escribir pruebas en el estilo de BDD, por ejemplo, iniciar métodos de prueba con should e introducir alguna característica separada con este método. When y then secciones se pueden reemplazar con solo comentarios, por ejemplo

@Test
public void should_do_something() {
    // given
    Something something = getSomething();

    // when
    something.doSomething();
    // then 
    assertSomething();

    // when
    something.doSomethingElse();
    // then 
    assertSomethingElse();
}

Mi opinión sobre los marcos mencionados:

• El problema con JBehave es que las pruebas parecen una nave espacial compleja. Por otro lado, tiene una salida bonita para sus especificaciones.

• spock es realmente genial. Sintaxis compacta, salida bonita, muchas funciones, escrita con el potente lenguaje Groovy, lo que significa la posibilidad de uso en combinación con geb PERO es maravilloso y puede ser muy importante para alguien.

• scalatest (escrito con scala) y easyb (escrito con groovy) tienen la misma desventaja que Spock. La notación "... should ..." and "Given ... Then". Las especificaciones están en archivos .story, y las implementaciones paso están en clases Java. Este enfoque funciona muy bien como una herramienta de colaboración y comunicación para definir las especificaciones, pero normalmente sería demasiada sobrecarga para la codificación de bajo nivel.

También creo que los marcos BDD más exitosos para Java son aquellos que no están escritos en Java, ya que el lenguaje Java no tiene tanta flexibilidad para la creación DSL (lenguaje específico del dominio) que Groovy o Scala tienen.