Tres antipatterns BDD

Antipatterns

Un antipattern es descrito por wikipedia 'como 'un patrón usado en sociales u operaciones o ingeniería de software que pueden ser utilizado pero es ineficaz o contraproducente en la práctica. Desarrollo orientado a comportamiento no es inmune a estos, así que aquí están tres antipatterns común mirar hacia fuera para al escribir características BDD.

1. 'como el usuario'

Decorar que el exterior de cada especificación ejecutable (es decir, función) debe ser algunas palabras explicando, en forma de 'historia de usuario', lo que la función es el objetivo de hacer. Típicamente estos comienzan 'Como usuario quiero', por ejemplo, en un escenario para una librería en línea que tenga 'Como usuario quiero buscar libros por categoría'. Y mientras que esto puede ser fácilmente comprendido por todos los actores del proyecto, mirarlo desde otra perspectiva 'Usuario' es un término demasiado amplio, homogeonising las variedades de los usuarios y sus necesidades en una sola entidad - 'el usuario'. Para contrarrestar esto considere la creación de un vocabulario de tipos de usuario diferente, sustituyendo el usuario genérico con un tipo de usuario específico cuando vea 'como usuario' por ejemplo,

Como comprador quiero filtrar los libros por categoría

o

Como cliente registrado en quiero ver mis últimos pedidos

Esto ayuda a aclarar la intención de la función y comunicarse más claramente en el resultado del negocio es dirigido en.

a menudo este anti-patrón se agrava más cuando escribimos historias, cuyo principal beneficiario no es el usuario final pero algunos actores de negocio. Tomemos el siguiente caso: el Departamento de marketing desea firmar usuarios por alguna empresa de terceros, listas de marketing. Por lo general la historia de usuario tendría este aspecto:

Como un usuario quiero ser notificado de ofertas especiales por cuidadosamente seleccionado de compañías

Sin embargo, es raramente el caso que el usuario está conduciendo esta necesidad, y el lenguaje de alguna manera se siente forzado. En este caso es nuestro Departamento de marketing que están impulsando esta necesidad, por lo que sería explicar la intención del escenario mejor y ser mucho más honestos, a reescribir esto como

Como el director de marketing quieren recolectar direcciones de correo electrónico al cliente para vender a empresas de terceros

Ahora cuando leemos esta historia podemos ver donde viene el requisito, y cuáles son los resultados de negocio esperados, que es lo que BDD se pretenden lograr.

2. ' cuando clasifico ' input.flooble-widgets [: primer]' con 'FooBar'

Si está ejecutando archivos de función como parte de una suite de pruebas automatizadas (por ejemplo, en un entorno de integración continua), que va a utilizar una herramienta como Behat, pepino o similar a un explorador web para determinar si una determinada función se ha completado o no. Es de suma importancia para escribir la BDD en la lengua de dominio de su negocio [1], y a menos que su cliente está en el negocio de la construcción por ejemplo de formularios en línea nunca debería ver cualquier referencia a elementos específicos de DOM (o posiblemente incluso valores de entrada) en su cuenta. Características deben capturar los criterios de aceptación para los resultados de negocio específico, no simplemente ser un lenguaje de scripts nivel superior para el selenio, siempre producen definiciones de paso como

Cuando me suscribo a la newsletter de

en lugar de

Y configurar el valor de ' entrada #newsletter-suscripción-casilla de verificación ' a '1'

y

Cuándo buscar artículos que contengan las palabras 'rockets'

en lugar de

Cuando puedo llenar en ' entradas #search-términos ' con 'rockets'
Y hacer clic en botón de botón de search #

La aplicación real de la definición de los pasos debe ser encapsulada utilizando el modelo de marco de página o elemento [2] por lo que eres capaz de hacer cambios en la aplicación que se desprenda de las circunstancias (por ejemplo, o si necesita asegurar el requisito aún funciona en una página rediseñada con diferentes ids de DOM). Sus características siempre deben ser escritos en la lengua de dominio de la empresa para garantizar la claridad de intenciones y que los actores técnicos y no técnicos son capaces de los entender completamente.

3. 'Y esperar 10 segundos'

Algunas de las características que está probando (por ejemplo los sistemas que se basan en sistemas de terceros con una latencia de red inestable o en páginas pesadas en javascript) pudieron exhibir retrasos en el movimiento de un estado a otro evitar nuevas medidas de llevado fuera. por ejemplo, puede que tenga que esperar una llamada de AJAX para completar antes de que se habilita un botón de 'continuar'. Un patrón común contra a menudo solía obviar esto y relacionado con el patrón el script anterior, es agregar un tiempo de espera a la función de.

El problema principal con esto es que mientras que está escrito en algo acercarse a la lengua de dominio, es poco probable que sea un requisito real. Tu cliente es muy poco probable que realmente desea que su usuario esperar diez segundos mientras que algunos no relacionados con acción produce, por lo pasos como estos que existen para asegurar que aspectos técnicos no funcional no dejar pruebas funcionales de ejecución deben ser enrolladas en contextos de elemento de página, ocultando la implementación de estas soluciones.

Que es - tres antipatterns común mirar hacia fuera al escribir sus características BDD - que son de alguna ayuda!

[1] http://domainlanguage.com [2] http://extensions.behat.org/page-object