tutorial test que pruebas funcionales ejemplo atdd aprender bdd fitnesse acceptance-testing

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



pruebas funcionales bdd (7)

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

JBehave (y NBehave recientemente agregó el mismo soporte) trabajan con archivos de prueba regulares, así que mientras que muchos otros marcos agregan "BDD taste tounit tests", las especificaciones / ejemplos de comportamiento basados ​​en texto 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 .

Las "pruebas" BDD existen en múltiples niveles diferentes de granularidad, hasta la visión inicial del proyecto. La mayoría de la gente conoce los escenarios. Algunas personas recuerdan que BDD comenzó con la palabra "debería" 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 de BDD.

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

Las pruebas de aceptación en realidad no obligan a las conversaciones, y por lo general funciona desde la suposición de que las pruebas que está escribiendo son las pruebas correctas. 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.

Intenta con "Me gustaría hablar contigo sobre el escenario donde ...". 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 estás sacando lo incorrecto. De verdad, honestamente, lo eres. Incluso si crees que no lo eres, es solo porque no entiendes la ignorancia de segundo orden. No sabes que no sabes, y eso está bien, siempre y cuando hayas encontrado los lugares donde podrías saber que no sabes. (No los encontrará a todos. No permita 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 lo que sucede cuando lo intenta. 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 sobre eso para estar menos equivocado, luego aceptar que todavía estás equivocado y buscarlo de todos modos. Escribir las pruebas demasiado pronto significa que tienes más posibilidades de equivocarte, y ahora es más difícil cambiar y todos piensan que tienes razón y el PM está midiendo tu velocidad y ahora estás 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 de BDD.

Por favor, 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.

Habiendo dicho eso, si debe comenzar con una herramienta, coloque a Slim detrás de Fitnesse para que pueda ejecutar Lovely Given / When / Thens sin tener que meterse con las tablas y los accesorios de Fit. GivWenZen está basado en Slim y cualquiera de ellos es GivWenZen . FitSharp es el equivalente para aquellos de ustedes en el espacio .NET. O simplemente use Cucumber, o SpecFlow, o suba un poco de DSL * personalizado que hará el trabajo bien por años.

Transparencia: * Escribí ese. 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.

De todos modos, ya tienen las conversaciones. Es solo gente. Ve a hablar

Las pruebas de xBehavior BDD implementadas 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.

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) , aún voy a escribir la prueba de la unidad, pero la llamaré una especificación porque voy a cambiarla (1) a verificar el comportamiento de la rutina, y (2) porque la prueba 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); } }

Mientras que BDD es más grande 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.

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

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 "marcos de BDD", el hablante normalmente significa un marco para escribir todos los tipos habituales de pruebas, pero con un giro BDD. Por ejemplo, en RSpec, todavía escribes pruebas unitarias; solo agrega el sabor BDD a ellos.