¿Las pruebas de BDD son pruebas de aceptación?

Question

O, si tiene pruebas de BDD, ¿necesita algo como Fitnesse?

Answer 1

TDC "pruebas" en varios diferentes niveles de granularidad, todo el camino hasta la visión inicial del proyecto. La mayoría de la gente conoce los escenarios. Algunas personas recuerdan que BDD started off with the word "should" como reemplazo de la "prueba" de JUnit como reemplazo de TDD. La razón por la que puse "pruebas" entre comillas es porque BDD no se trata realmente de pruebas; se centra en encontrar los lugares donde hay una falta o falta de coincidencia de comprensión.

Debido a ese enfoque, las conversaciones son mucho más importantes que las herramientas BDD.

Voy a decir eso de nuevo.Las conversaciones son mucho más importantes que las herramientas BDD.

Las pruebas de aceptación en realidad no obligan a las conversaciones, y por lo general parte de la suposición de que las pruebas que está escribiendo son las adecuadas. En BDD asumimos que no sabemos lo que estamos haciendo (y probablemente no sepamos que no sabemos). Es por eso que utilizamos cosas como "Dado, cuándo, luego", para que podamos tener conversaciones en torno a los escenarios y/o ejemplos a nivel de unidad. (Esos son los dos niveles con los que la mayoría de la gente está familiarizada, el equivalente de las pruebas de aceptación y las pruebas unitarias, pero sube la escala).

No los llamamos "pruebas de aceptación" porque no puede preguntarle a una persona de negocios "Ayúdenme con mi prueba de aceptación". Te mirarán con una mirada extraña y con los ojos entrecerrados y luego te despedirán como esa chica geek. El 93% de ustedes no quiere eso.

Pruebe "Me gustaría hablar con usted sobre el escenario donde ..." en su lugar. O, "¿Me puedes dar un ejemplo?" Cualquiera de estos son buenos. Llamarlos "Pruebas de aceptación" comienza a hacer que las personas piensen que realmente estás haciendo pruebas, lo que implicaría que sabes lo que estás haciendo y solo quieres asegurarte de haberlo hecho. En ese punto, las conversaciones tienden a enfocarse en cuán rápido puedes sacar lo incorrecto, en lugar de sobre el hecho de que estás saliendo mal.

Y te estás equivocando. Really, honestly, you are. Incluso si crees que no lo eres, es solo porque no entiendes la ignorancia de segundo orden. Usted no sabe que no sabe, y eso está bien, siempre y cuando haya encontrado los lugares donde podría saber que no sabe. (No los encontrará todos. No deje que la paradoja de categorización lo mantenga despierto por la noche.)

La única manera de hacerlo bien es obtener todos los requisitos por adelantado, y usted sabe que pasa cuando intentas eso. Está bien. Es Cascada. ¿Recuerdas el tiempo extra? El trabajo de fin de semana? ¿Los siete años en los que ni una sola cosa de tu creación llegó a la producción? Si quieres evitar eso, solo tienes una oportunidad: asumir que estás equivocado, tener algunas conversaciones al respecto para que esté menos errado, luego aceptar que eres todavía incorrecto e intentarlo de todos modos. Escribir pruebas demasiado temprano significa que tiene incluso más posibilidad de equivocarse, y ahora es más difícil cambiar y todos piensan que tiene razón y el PM está midiendo su velocidad y ahora está comprometido a estar equivocado por otras 2 semanas. Y, lo que es peor, estás a punto de probar que también estás equivocado.

Una vez más. Las conversaciones son mucho más importantes que las herramientas BDD.

Por favor, no se fije en las herramientas. Las herramientas son solo un mecanismo para capturar las conversaciones y asegurarse de que se reproduzcan en el código. Los escenarios no son un reemplazo para las conversaciones, del mismo modo que una tarjeta de índice 3 x 5 es un reemplazo de los requisitos.

Una vez que debe comenzar con una herramienta, coloque Slim detrás de Fitnesse para que pueda ejecutar Lovely Given/When/Thens sin tener que meterse con las mesas y los accesorios de Fit. GivWenZen se basa en Slim y cualquiera de ellos rocas. FitSharp es el equivalente para aquellos de ustedes en el espacio .NET. O simplemente use Cucumber, o SpecFlow, o knock up a little custom DSL* que hará el trabajo bien durante años.

Transparencia: * Escribí eso. Y partes de JBehave. Ojalá lo hubiéramos llamado "No concentrarse en BDD-herramientas-Comprometerse". Podría estar muy involucrado en otras partes de BDD.Además, Dan North me comprará una pinta si puedo transmitir este mensaje, por lo que no es exactamente un consejo imparcial.

Independientemente: ya tienen las conversaciones. Es solo gente. Ve a hablar

Answer 2

No sé si hay algo así, estrictamente hablando, como una "prueba BDD". BDD es una filosofía que sugiere cómo puede interactuar y colaborar mejor con las partes interesadas para completar un proyecto complejo. No hace recetas directamente para la mejor forma de escribir pruebas. En otras palabras, es probable que aún tenga todos los tipos habituales de pruebas (incluidas las pruebas de aceptación) en un proyecto de filosofía BDD.

Cuando oye hablar de "frameworks BDD", el altavoz usualmente significa un marco para escribir todos sus tipos usuales de pruebas pero con un giro BDD. Por ejemplo, en RSpec, todavía escribes pruebas unitarias; solo agrega el sabor BDD a ellos.

Answer 3

Mientras que el BDD es mayor que el alcance de las pruebas, existen pruebas de BDD. Estas pruebas son pruebas unitarias que siguen el lenguaje BDD.

Dado un contexto inicial (los datos), Cuando ocurre un evento, entonces asegure algunos resultados.

Existen algunos buenos frameworks BDD disponibles dependiendo de su idioma de preferencia. JBehave para Java RSpec para Ruby NBehave para .NET

Answer 4

me gusta hacer una distinción entre "especificaciones" y "pruebas".

Si estoy cubriendo un método llamado GetAverage(IEnumerable<int> numbers), voy a escribir una prueba unitaria más o menos estándar.

Si estoy cubriendo un método llamado CalculateSalesTax(decimal amount, State state, Municipality municipality), todavía voy a escribir la prueba de unidad, pero la llamaré una especificación porque la voy a cambiar (1) para verificar el comportamiento de la rutina y (2) porque la prueba en sí documentará tanto la rutina como sus criterios de aceptación.

considerar:

[TestFixture] 
public class When_told_to_calculate_sales_tax_for_a_given_state_and_municipality() // the name defines the context 
{ 
    // set up mocks and expected behaviour 
    StateSalesTaxWebService stateService 
     = the_dependency<IStateSalesTaxWebService>; 
    MunicipalSurchargesWebService municipalService 
     = the_dependency<IMunicipalSurchargesWebService>; 

    stateService.Stub(x => x.GetTaxRate(State.Florida)) 
     .Return(0.6); 
    municipalService.Stub(x => x.GetSurchargeRate(Municipality.OrangeCounty)) 
     .Return(0.05); 

    // run what's being tested 
    decimal result = new SalesTaxCalculator().CalculateSalesTax 
     (10m, State.Florida, Municipality.OrangeCounty); 

    // verify the expected behaviour (these are the specifications) 
    [Test] 
    public void should_check_the_state_sales_tax_rate() 
    { 
     stateService.was_told_to(x => x.GetTaxRate(State.Florida)); // extension methods wrap assertions 
    } 

    [Test] 
    public void should_check_the_municipal_surcharge_rate() 
    { 
     municipalService.was_told_to(x => x.GetSurchargeRate(Municipality.OrangeCounty)); 
    } 

    [Test] 
    public void should_return_the_correct_sales_tax_amount() 
    { 
     result.should_be_equal_to(10.65m); 
    } 
} 

Answer 5

JBehave (y NBehave añadido recientemente el mismo soporte) trabajan con archivos de pruebas regulares por lo que mientras muchos otros marcos agregan "TDC pruebas de sabor tounit" las especificaciones de comportamiento basados ​​en texto/ejemplos creados con JBehave son adecuados para las pruebas de aceptación. Y no, no necesitas fitnesse para eso.

Para tener una idea de cómo funciona, sugiero JBehaves 2min tutorial.

Answer 6

Para las pruebas de BDD en Flex puede probar GivWenZen-flex verifique http://bitbucket.org/loomis/givwenzen-flex. Existen

Saludos, Kris

Answer 7

xCompetencias Las pruebas de BDD implementadas correctamente son criterios de aceptación de usuario impulsados ​​por robo.

xEspecificación Las pruebas BDD son normalmente pruebas unitarias y es poco probable que sean criterios aceptables de aceptación del usuario.