Historias de usuarios para el código

Question

Supongamos que tengo un montón de historias de usuarios (como resultado de la sesión de plaining que realicé con mi equipo). No tengo ningún código de la aplicación todavía y va a empezar con mi 'A' o más altos Historias de Prioridad/Epopeyas

decir, por ejemplo

"como usuario debería ser capaz de buscar más usuarios para que pueda agregar más amigos en el sitio web "

Entonces, ¿cómo debe el equipo ir sobre la codificación de la aplicación mientras se hace TDD.

• equipo comienza con la creación de pruebas unitarias, es decir, .que cuidar de modelos Creación

• Entonces todo el mundo tiene una historia y comienza a escribir pruebas funcionales para crear mis controladores/Vistas (por lo que debe estar haciendo pruebas de integración al escribir pruebas funcionales)

• A continuación, realice las pruebas de integración

De hecho, estoy c Si todas las pruebas de integración funcionan (es decir, todas las pruebas funcionales de la unidad deben pasar)

Por lo tanto, si la aplicación está recién comenzando (es decir, no se ha escrito ningún código). ¿Cuál es el proceso que las personas generalmente toman para TDD/BDD cuando recogen una historia y comienzan, para implementar una aplicación desde cero?

Answer 1

"De hecho, estoy confundido cómo las pruebas de integración encajan in.if todo el trabajo pruebas de integración (es decir, todos los funcionales, pruebas de unidades deben pasar todos modos)"

depende. Claro, es posible escribir pruebas de integración de tal manera que todas las pruebas de unidad y funcionales pasen. Es mucho más difícil.

Imagine que tiene 3 modelos, 3 controladores y 3 vistas. Imagine que todos son súper simples sin condiciones o bucles y tienen un método cada uno.

Ahora puede (unidad) probar cada uno de estos para un total de 9 afirmaciones y tener una cobertura total. Puede lanzar una prueba de integración para asegurarse de que todas estas cosas funcionen bien juntas.

Si por el contrario omite unidades/funcionales y necesita tener una cobertura completa, necesitará 27 afirmaciones (3 x 3 x 3).

En la práctica, las cosas son más complicadas, por supuesto. Necesitará una cantidad mucho mayor de pruebas de integración para obtener el mismo nivel de cobertura.

Además, si practica TDD/BDD, la mayoría de las veces terminará con muchas pruebas de unidad. La prueba de integración está ahí para asegurarse de que todas estas piezas encajen bien y hagan lo que el cliente desee. Las piezas mismas han sido probadas individualmente por las pruebas unitarias.

Answer 2

Primero, rompa la historia. Necesitará:

1. A Objeto del usuario: ¿Qué hace? Cree algunas pruebas para resolver esto y escriba el código
2. Una forma de buscar usuarios; tal vez un SearchUserService? Una vez más pruebas de crear y escribir el código
3. Una manera de conectar a los usuarios ...

Ahora, usted tiene el modelo. Luego, haces lo mismo con los controladores. Cuando funcionan, comienzas con las vistas.

O, cuando eres un profesional y lo has hecho miles de veces, es posible que puedas rodar varios pasos a la vez.

Pero primero debe cortar el problema en trozos digeribles.

Siguiente para las pruebas de integración. Simularán lo que hace un usuario. En el caso general, debe escribir un conjunto de pruebas unitarias (simplemente se llaman pruebas de integración, pero también debería poder ejecutarlas automáticamente). Estas pruebas necesitan hablar con la aplicación web como lo hace el usuario, por lo que necesita un navegador web simulado, etc.

Puede intentar httpunit o env.js para esto.

Answer 3

Aquí es donde normalmente comenzamos con un Sprint 0 y en esta primavera es donde tendremos lo que XP llama una sesión de Spike (o una sesión de código de tiro). En esta sesión es donde puede comenzar la creación de prototipos.

En su sesión, escriba algunas pruebas de aceptación del usuario (preferiblemente en el formato BDD) y luego comience a escribir una prueba primero para que coincida con uno de sus UAT.

Por ejemplo:

se solicita

Dada una búsqueda donde el nombre de usuario es "TESTUSER" 1 resultado debe ser devuelto.

Con esto, ahora tiene un objetivo para su primera prueba, que debe escribir, luego comience a escribir el código para que la prueba pase. A medida que avance, debería comenzar a ver cómo se debe armar la aplicación para completar la historia.

Entonces comenzaría en el siguiente edificio sprint de historias/tarea de completar la función según sea necesario, en base a lo que has descubierto en el sprint 0.

Answer 4

Muy buena pregunta! El modo TDD/BDD sugiere que tome las historias de los usuarios y escriba puntos de validación (lea las pruebas de alto nivel). Usan GWT (Given/When/Then) y hablan de la siguiente manera.

"como un usuario debería ser capaz de buscar más usuarios para que pueda añadir más amigos en el sitio web"

given the website URL 
when the site loads 
then a search field should be visible/accessible. 

Ésta es su primera pieza de retroalimentación y la primera opportuniuty para iterar con el producto propietario. Haga preguntas como ¿a dónde debe ir la barra de búsqueda? ¿Se debe completar automáticamente? Etc. A continuación, asignar "el comportamiento de los objetos de interfaz de usuario Estos también tienen puntos de validación

Esto sería definir el comportamiento del botón de búsqueda:..

given a go button next to the search field 
when then button is clicked 
then a search should be performed 

esto sería describir la lógica de su búsqueda:

El primer punto de validación describiría el comportamiento de vincular el botón de búsqueda del controlador con un modelo arbitrario que implementa el algoritmo de búsqueda. El segundo punto de validación describe el algoritmo de búsqueda en sí. dently y se pueden diseñar en paralelo. También le ofrece una API agradable y funciones pequeñas fáciles de planificar para repetir. También le da la capacidad de iterar/refinar en cualquier pieza del rompecabezas sin afectar el resto del pastel.

Actualización También quiero mencionar que a lo que me refiero como puntos de validación puede asociarse libremente con UATs o Pruebas de aceptación del usuario. No te obsesiones con los términos porque son irrelevantes. Enfócate en la idea detrás de ellos. Debe tomar la historia del usuario y dividirla en especificaciones. (se puede hacer en uno o más pases utilizando UAT o puntos de validación o ambos o beans mágicos solo asegúrate de dividirlos). Si lo que has roto en tus historias de usuario se puede escribir en una herramienta como FitNesse, JUnit o Luego, RSpec utiliza una de estas herramientas; de lo contrario, necesita una conversación adicional (¿son demasiado vagas sus historias de usuario?) U otra pasa por lo que debe analizar más (UAT a puntos de validación). No se obsesione con las herramientas y sienta que necesita automatizar todo desde el principio. Deje Selenium solo hasta que obtenga el proceso manual. Finalmente, si desea especificaciones que se puedan escribir en forma de prueba programática en este momento, debería poder usar algo tan simple como JUnit para comenzar a codificar. Cuando seas mejor/más elegante podrás elegir el corredor de historias de EasyB o RSpec y otras cosas.

Answer 5

Si está haciendo TDD, comienza con una prueba que muestra que el sistema no realiza el comportamiento requerido descrito por la historia del usuario. Cuando eso está fallando de la manera que usted espera, con diagnósticos útiles, luego comienza a implementar el comportamiento agregando o modificando clases, primero trabajando la prueba de la unidad.

Por lo tanto, en TDD escribe pruebas de integración antes de escribir las pruebas unitarias.

Para arrancar todo el proceso, generalmente se escribe un "esqueleto andante": un sistema que realiza la porción más delgada de funcionalidad realista posible. El esqueleto andante construya la infraestructura de prueba de integración contra una funcionalidad simple.

El resto del proyecto luego rellena ese esqueleto.