2010-07-13 19 views
7

Estoy empezando con BDD y estoy tratando de crear una aplicación pequeña, por lo que puedo ver que funciona en un entorno real, pero tengo problemas para decidir qué debería ser una característica. Estoy construyendo una pequeña tienda.BDD, ¿qué es una función?

Decidí que "Comparar productos" será una función y "El usuario puede realizar el pago como invitado" será uno, pero para llegar a eso, primero debo enumerar los productos.

Mi pregunta es, ¿debería haber "Debería haber una lista de productos" como característica?

Gracias!

Respuesta

4

Probablemente sea una característica, pero intente redactarla desde el punto de vista de un usuario. ¿Qué le ofrece esta lista de productos?

  • usuario debería ser capaz de obtener una visión general de los productos ofrecidos
  • usuario debe ser capaz de ordenar y reordenar los productos en nombre, precio, disponibilidad.
2

Es bastante difícil comenzar a hacer BDD. Lo único que ayuda a tener confianza en tus habilidades y en todo el enfoque es escribir escenarios de prueba y el código que los ejecuta. Sugeriría que no hagas más difícil una situación ya compleja y confusa. Elija cualquier tarea que necesite implementar, abra un archivo de texto en blanco y trate de explicar el uso de oraciones simples. Cada oración debe comenzar con una de tres palabras clave: dando, cuando y luego. Usando su marco BDD favorito, escriba el código que analizará estas oraciones y estimulará la aplicación para que entre en el estado de inicio (dada), ejecute algunos comandos (cuando) y afirme el estado de transición (luego). El código de la aplicación puede comenzar a partir de meros simulacros. Reemplace gradualmente esos simuladores con código creado gradualmente y haga crecer su aplicación con mayor confianza y niveles de calidad.

1

La historia del usuario es una característica. Algo que puede ser expresada en formato:

  • Como papel
  • me gustaría hacer algo
  • Para que objetivo

P. ej

  • Como usuario
  • Me gustaría ser capaz de comparar productos
  • De modo que pueda seleccionar un producto que satisface mis necesidades de una mejor manera

  • como invitado

  • I me gustaría pagar mi carrito de compras
  • Para que pueda completar la compra

Cada característica tiene que ser confirmada por una serie de escenarios de Dado-Cuando-Por supuesto.

1

Básicamente, estás preguntando qué es una característica. Piénselo, usted tiene una historia, una historia describe una característica que usted (u otras personas involucradas) quiere para su aplicación. Usualmente tiene la forma de: Como usuario, quiero ver la lista de productos. Puede agregar notas a esta historia, para hacerlo más claro. Pero luego viene el comportamiento específico (que eventualmente probará en contra): hay un número infinito de comportamientos que se ajustan a esta historia (piense en la vista de los productos y en las muchas formas de presentarlos). Su enfoque, en BDD, es encontrar el comportamiento que su suite necesita (uso la aplicación y no el usuario, porque a veces debe decidir por el usuario) - hablando con tanta gente como sea posible, probando cosas e iterando terminó.

Es como ir de arriba a abajo, siempre tratando de enfocarse en el comportamiento, siendo más específico sobre la marcha. Si lo piensas, dado un comportamiento (es decir, un conjunto de pruebas), hay un número infinito de implementaciones. Es por eso que el objetivo de BDD es comprender verdaderamente el comportamiento experimentando y hablando, siempre hay un grado de libertad.

1

¿Más importante sería averiguar qué quiere hacer el usuario con la lista de productos? la función proporcionará algo valioso para el usuario. por lo que en su caso sería

  • Elija un producto para ver una lista de productos
  • Elija productos x para comparar entre una lista de productos
  • Otros
0

para determinar, si un requisito es una característica/historia de usuario explícita, puede usar las pautas de diseño/documentación basada en tareas (por ejemplo, http://www.sprez.com/articles/task-documentation-design.html). Tales conceptos reconocen que un usuario de un sistema quiere lograr un resultado específico. Por lo general, saber algo (como qué productos están disponibles) es solo un paso en el proceso de compra/venta/construcción/etc. Un buen punto de partida en BDD es escribir los temas que usaría como capítulos en su usuario manual. Estos temas suelen ser las características que va a proporcionar en su solución de software. Un buen marco que admite dicho enfoque de especificación por ejemplo es Concordion (http://concordion.org). Vea la descripción de "pruebas de aceptación en inglés sencillo" (http://gojko.net/2009/09/01/acceptance-testing-in-plain-english-with-concordion-net/).