Comprender BDD con un ejemplo práctico

Question

Intento unirme al enfoque de desarrollo conducido por el comportamiento, pero para usarlo necesito entender cómo pensar de esa manera.

me gustaría probarlo en un nuevo proyecto personal que estoy empezando ahora mismo (utilizaré RoR)

El proyecto proporcionará API para recopilar datos desde aplicaciones externas, que proporcionará una autenticación sistema (diseño), varios modelos para recopilar datos según sea necesario, y un sistema de pago para comprar suscripciones que proporcionará algunas funciones exclusivas.

¿Qué tipo de pruebas debo realizar para cubrir todas estas funcionalidades, pero SECAS?

Pensé que debería usar tanto RSpec como Cucumber. Para Devise, seguiré la documentación en su sitio web, pero no tengo claro qué tipo de pruebas debo realizar para verificar que los datos se hayan recopilado correctamente y que se muestren correctamente al usuario y qué herramientas se usan para esa tarea. Además, si pudiera proporcionar un ejemplo simple de cómo organizaría las pruebas y el desarrollo para este tipo de proyecto, lo ayudará (no estoy preguntando sobre el código de prueba real -porque realmente lo veo depende de la implementación-, sino sobre el proceso de desarrollo y TIPO de pruebas que realizarías). Si necesita más detalles para elegir, infórmeme y siéntase libre de inventarlo, ya que es para fines educativos.

Answer 1

No creo que pueda haber ninguna mención de BDD sin alguien que repican en que todo se trata de la comunicación. Así que seré ese tipo: ¡todo se trata de la comunicación! El valor real es la exploración de la funcionalidad en términos accesibles con diferentes partes interesadas para establecer lo que el sistema necesita hacer de forma transparente. Con todo el mundo hablando el mismo idioma, es mucho más fácil comunicar los objetivos. Cuando se trata de la implementación, los desarrolladores saben lo que hacen, las partes interesadas saben lo que están obteniendo y no deberían haber demasiadas sorpresas (a excepción de las cosas que omitió/capturó incorrectamente/todavía no se han dado cuenta).

Por lo tanto, salga, hable con sus partes interesadas y resuelva qué la persona encargando el sistema lo quiere.Si se trata de un esfuerzo individual, vas a necesitar usar varios sombreros diferentes.

Sus pruebas BDD cubrirán el comportamiento del sistema - unidades de la funcionalidad deseada. Todavía tendrá que hacer pruebas unitarias, etc., sin cambios allí.

Como propietario de un producto, piense en lo que desea que el sistema para hacer - no cómo. Probablemente no le importe cómo funcionan las cosas, siempre y cuando funcionen. Si eres un desarrollador, este será probablemente el cambio difícil en el pensamiento. Cuando comencé a buscar en BDD, estaba convencido de que tenía sentido realizar los recorridos de UI y los detalles técnicos, etc., en los escenarios. No es así Eso pertenece a las definiciones de pasos. Como desarrollador, puede definir todos los cómo cosas allí.

En cuanto a mantenerlo SECO ... Escriba sus escenarios exactamente como necesita para capturar el comportamiento requerido. Luego, puede preocuparse por la refactorización y la identificación de oportunidades para volver a usar el paso. El uso de expresiones regulares también ayudará aquí, hasta cierto punto. Es tentador ser súper imperativo y tener todo un conjunto de pasos reutilizables, pero es probable que se dé cuenta de que todo es muy frágil cuando un cambio en un solo paso recorre todos sus escenarios, no solo el que se suponía que debía afectar. Si está interesado en alguna forma de automatización web, consulte la pirámide de automatización web.

recursos útiles (y un montón de ejemplos):

http://books.openlibra.com/pdf/cuke4ninja-2011-03-16.pdf < impresionante libro electrónico gratuito - divertido de leer, también.

http://www.slideshare.net/lunivore/behavior-driven-development-11754474 < ¡Liz realmente sabe lo que hace!

http://dannorth.net/2011/01/31/whose-domain-is-it-anyway/

https://www.google.co.uk/search?q=declarative+vs+imperative+BDD < va el equipo declarativa!

Answer 2

no estoy seguro de que este se adapte a sus necesidades exactas, pero esta es la forma en que hago BDD (ejemplo es una aplicación web):

actúa como si estuvieras sentado frente a la computadora como un usuario de la aplicación. Anote los pasos que debe realizar para alcanzar uno de los casos de uso, por ejemplo:

Vaya a del sistema url sesión Seleccione la función que necesite anote los datos pertinentes para ejecutar la función Haga clic en el botón para inicie la función Espere que el sistema responda Asegúrese de que los datos en la pantalla coincidan con los datos que espera.

Si alguno de estos pasos no se ejecuta o los datos son incorrectos, la prueba ha fallado.

Una vez que tenga esto en un archivo de prueba, a continuación, utilice Gherkin/Cucumber/Webdriver para implementar el código requerido para ejecutar cada uno de los pasos. Cada método de esto es reutilizable, por lo que una vez que haya implementado el inicio de sesión en un lugar, debería funcionar en cualquier lugar que lo llame.

Answer 3

para la prueba con el pepino o rspec para idear probar esto

ver esto - cucumber/rspec o on github