SlideShare ist ein Scribd-Unternehmen logo
1 von 10
Downloaden Sie, um offline zu lesen
Behavior Driven
             Development
                (BDD)
  Desarrollo Dirigido por Comportamiento
Gestión de Sistemas Informatizados. Prof. Daniel Molina Cabrera

Escuela Superior de Ingeniería - Universidad de Cádiz



                                               Raquel García García
                                          Inmaculada García Romero
                                             Virginia Serrano García
Indice:

1. Introducción

2. Principios fundamentales

3. Ciclo de desarrollo BDD

4. Herramientas y frameworks de BDD
1. Introducción

• Nace en 2003 de manos de Dan North como una
  evolución del pensamiento tras el Test Driven
  Development    (TDD)    y   también   tomando
  conceptos del Domain Driven Design (DDD).

• Uniendo ambas ideas en un todo integrado que
  hace más evidente la relación entre estos dos
  caminos de desarrollo de software.
1. Introducción
 El desarrollo dirigido por comportamiento, o
 Behavior Driven Development (BDD) es una
 técnica de Desarrollo Agil De Software, esto es,
 una técnica de programación que cuestiona el
 comportamiento de una aplicación antes y
 durante el proceso de desarrollo.

 De esta forma, se fomenta la colaboración entre
 desarrolladores, testers, analistas y personas del
 negocio en un proyecto de software.
1. Introducción
Mediante preguntas tales como:

  “¿Qué debería hacer esta aplicación?”
                       o
 “¿Qué debería hacer esta parte?” ,

los desarrolladores pueden identificar brechas en
la comprensión del problema del dominio y hablar
con sus pares o expertos del dominio para
encontrar las respuestas.
1. Introducción
Los desarrolladores guiados por comportamiento
usan su lenguaje nativo en combinación con el
lenguaje ubicuo de DDD para describir el propósito
y beneficios de su código.

Esto les permite enfocarse en por qué el código
debe ser creado, antes que en los detalles
técnicos, y minimiza la traducción entre el
lenguaje técnico en el cuál se escribe el código y el
lenguaje de dominio hablado por las personas del
negocio, usuarios, interesados, gerentes de
proyecto, etc.
1. Introducción
 Objetivo:

    Contribuir a que el desarrollo de software se
 centre en la construcción de elementos,
 siguiendo una prioridad, que tengan un valor
 verificable para el negocio.

    BDD permite un entendimiento más global del
 sistema a crear, un entendimiento común de
 todos los involucrados y ayuda a eliminar malos
 entendidos sobre lo que el sistema debe hacer.
2. Principios fundamentales
 Suficiente es Suficiente: La planificación por adelantado,
 el análisis y el diseño tienen un rendimiento decreciente.
 No debemos hacer menos de lo que se necesita para
 empezar, pero más que eso es un esfuerzo inútil.

 Entregar valor a nuestros “stakeholders”: Si te
 encuentras haciendo algo que no entrega valor o
 incrementa tu habilidad/posibilidad de entregar valor, deja
 de hacerlo y haz algo distinto.

 Todo es comportamiento: Ya sea a nivel de código, de
 aplicación o más allá, podemos usar el mismo pensamiento
 y la misma lingüística para describir comportamiento a
 cualquier nivel de granularidad.
3. Ciclo de desarrollo BDD
1.   Discusión. Desarrolladores, testers, expertos de dominio y
     el dueño de producto se juntan y discuten la historia,
     gradualmente descomponiendo y destilando el
     comportamiento en un conjunto de especificaciones simples.

2.   Decisión. El dueño de producto decide cuando la
     especificación cumple suficientemente el comportamiento
     esperado y está de acuerdo con los casos de ejemplo y
     demostración de la historia y cierra el alcance de la misma.

3.   Desarrollo. Los testers refinan los ejemplos de la
     especificación y los desarrolladores instrumentan las
     especificaciones creando primero pruebas que fallan y
     después implementando la funcionalidad.

4.   Demostración. Una vez que todos los tests pasan la
     historia puede ser demostrada al dueño de producto.
4. Herramientas de BDD

 Concordion: es un framework Java de Software
 Libre que permite convertir especificaciones en
 texto común sobre requerimientos en pruebas
 automatizadas.

 JBehave: es un framework Java para mejorar la
 colaboración entre desarrolladores, QA, analistas
 de negocio, Dueño Del Producto y todos los
 miembros del equipo a través de escenarios
 automatizados y legibles.

Weitere ähnliche Inhalte

Was ist angesagt?

BDD - Desarrollo dirigido por comportamiento
BDD - Desarrollo dirigido por comportamientoBDD - Desarrollo dirigido por comportamiento
BDD - Desarrollo dirigido por comportamiento
Agustin Ramos
 
Revisión de código fuente de manera ágil
Revisión de código fuente de manera ágilRevisión de código fuente de manera ágil
Revisión de código fuente de manera ágil
Jose Luis Bugarin Peche
 

Was ist angesagt? (20)

BDD - Desarrollo dirigido por comportamiento
BDD - Desarrollo dirigido por comportamientoBDD - Desarrollo dirigido por comportamiento
BDD - Desarrollo dirigido por comportamiento
 
Devsecops superstar un movimiento masivo
Devsecops superstar un movimiento masivoDevsecops superstar un movimiento masivo
Devsecops superstar un movimiento masivo
 
TDD y Python
TDD y PythonTDD y Python
TDD y Python
 
Scrum y craftsmanship
Scrum y craftsmanshipScrum y craftsmanship
Scrum y craftsmanship
 
Nexus y la Deuda Tecnica
Nexus y la Deuda TecnicaNexus y la Deuda Tecnica
Nexus y la Deuda Tecnica
 
TDD talk
TDD talkTDD talk
TDD talk
 
Devops Maturity Assessment Model - Ágiles 2019
Devops Maturity Assessment Model - Ágiles 2019Devops Maturity Assessment Model - Ágiles 2019
Devops Maturity Assessment Model - Ágiles 2019
 
Meetup bdd & tdd: aprovecha_su_poder
Meetup bdd & tdd: aprovecha_su_poderMeetup bdd & tdd: aprovecha_su_poder
Meetup bdd & tdd: aprovecha_su_poder
 
Buenas practicas desarrollando software
Buenas practicas desarrollando softwareBuenas practicas desarrollando software
Buenas practicas desarrollando software
 
Revisión de código fuente de manera ágil
Revisión de código fuente de manera ágilRevisión de código fuente de manera ágil
Revisión de código fuente de manera ágil
 
Módulo 4. Desarrollador ágil
Módulo 4. Desarrollador ágilMódulo 4. Desarrollador ágil
Módulo 4. Desarrollador ágil
 
Módulo 6. Agile Testing
Módulo 6. Agile TestingMódulo 6. Agile Testing
Módulo 6. Agile Testing
 
Devsecooops Los Caso de no éxito en DevSecOps
Devsecooops Los Caso de no éxito en DevSecOpsDevsecooops Los Caso de no éxito en DevSecOps
Devsecooops Los Caso de no éxito en DevSecOps
 
Devops Adoption Roadmap v 2.7 Agiles Colombia 2020
Devops Adoption Roadmap v 2.7 Agiles Colombia 2020Devops Adoption Roadmap v 2.7 Agiles Colombia 2020
Devops Adoption Roadmap v 2.7 Agiles Colombia 2020
 
Yo soy Dev, yo soy Ops y somos dos en un equipo
Yo soy Dev, yo soy Ops y somos dos en un equipoYo soy Dev, yo soy Ops y somos dos en un equipo
Yo soy Dev, yo soy Ops y somos dos en un equipo
 
DevSec Oops, los casos de no éxito de DevSecOps
DevSec Oops, los casos de no éxito de DevSecOpsDevSec Oops, los casos de no éxito de DevSecOps
DevSec Oops, los casos de no éxito de DevSecOps
 
15 Upm Solo Pruebas 2009
15 Upm Solo Pruebas 200915 Upm Solo Pruebas 2009
15 Upm Solo Pruebas 2009
 
Módulo 5. El rol del Scrum Master
Módulo 5. El rol del Scrum MasterMódulo 5. El rol del Scrum Master
Módulo 5. El rol del Scrum Master
 
Devops Adoption Roadmap v.2.6
Devops Adoption Roadmap v.2.6Devops Adoption Roadmap v.2.6
Devops Adoption Roadmap v.2.6
 
Tw ¿Por qué elegir ágil?
Tw   ¿Por qué elegir ágil? Tw   ¿Por qué elegir ágil?
Tw ¿Por qué elegir ágil?
 

Andere mochten auch (20)

Guía de Dropbox
Guía de DropboxGuía de Dropbox
Guía de Dropbox
 
Modulo ii gp
Modulo ii gpModulo ii gp
Modulo ii gp
 
Presentación2
Presentación2Presentación2
Presentación2
 
Medios de pago
Medios de pagoMedios de pago
Medios de pago
 
CorelDraw parte 1...
CorelDraw parte 1...CorelDraw parte 1...
CorelDraw parte 1...
 
CorelDraw parte 1...
CorelDraw parte 1...CorelDraw parte 1...
CorelDraw parte 1...
 
Titular Blog
Titular Blog Titular Blog
Titular Blog
 
Exoe h07 tarea exoe periodo iii
Exoe h07 tarea exoe periodo iiiExoe h07 tarea exoe periodo iii
Exoe h07 tarea exoe periodo iii
 
Pautas de actuación ante la realización de las tareas escolares en la familia
Pautas de actuación ante la realización de las tareas escolares en la familiaPautas de actuación ante la realización de las tareas escolares en la familia
Pautas de actuación ante la realización de las tareas escolares en la familia
 
Modulo ii cce
Modulo ii   cceModulo ii   cce
Modulo ii cce
 
Rafa Rotaeche clausura
Rafa Rotaeche clausuraRafa Rotaeche clausura
Rafa Rotaeche clausura
 
Presentaciã³n1[1]
Presentaciã³n1[1]Presentaciã³n1[1]
Presentaciã³n1[1]
 
Alexandra panezo
Alexandra panezoAlexandra panezo
Alexandra panezo
 
Que es la cultura
Que es la culturaQue es la cultura
Que es la cultura
 
Modulo5 cap.1 lolis
Modulo5 cap.1 lolisModulo5 cap.1 lolis
Modulo5 cap.1 lolis
 
Nutricion
NutricionNutricion
Nutricion
 
2014_ Benveniste
2014_ Benveniste2014_ Benveniste
2014_ Benveniste
 
Guía de referencia - Scratch
Guía de referencia - ScratchGuía de referencia - Scratch
Guía de referencia - Scratch
 
Presentacion g20 ivan
Presentacion  g20 ivanPresentacion  g20 ivan
Presentacion g20 ivan
 
7 herramientas ...
7 herramientas ...7 herramientas ...
7 herramientas ...
 

Ähnlich wie (Behavior driven development (bdd ) [sólo lectura])

Behavior1
Behavior1Behavior1
Behavior1
arajar
 
Fases en el desarrollo de un programa
Fases en el desarrollo de un programaFases en el desarrollo de un programa
Fases en el desarrollo de un programa
Heidiie Hdz
 
Díme que desarrollas y te diré que metodología usar
Díme que desarrollas y te diré que metodología usarDíme que desarrollas y te diré que metodología usar
Díme que desarrollas y te diré que metodología usar
Kiberley Santos
 
Pracicas de Ingenieria de Software
Pracicas de Ingenieria de SoftwarePracicas de Ingenieria de Software
Pracicas de Ingenieria de Software
eeencalada
 

Ähnlich wie (Behavior driven development (bdd ) [sólo lectura]) (20)

Presentación MeRinde 6CNSL Abril 2010
Presentación MeRinde 6CNSL Abril 2010Presentación MeRinde 6CNSL Abril 2010
Presentación MeRinde 6CNSL Abril 2010
 
Behavior1
Behavior1Behavior1
Behavior1
 
Behavior Driven Development(Abraham Infante).pdf
Behavior Driven Development(Abraham Infante).pdfBehavior Driven Development(Abraham Infante).pdf
Behavior Driven Development(Abraham Infante).pdf
 
Metodologías de Desarrollo de Software
Metodologías de Desarrollo de SoftwareMetodologías de Desarrollo de Software
Metodologías de Desarrollo de Software
 
METODOLOGÍAS ÁGILES EN TI
METODOLOGÍAS ÁGILES EN TIMETODOLOGÍAS ÁGILES EN TI
METODOLOGÍAS ÁGILES EN TI
 
METODOLOGÍAS ÁGILES
METODOLOGÍAS ÁGILESMETODOLOGÍAS ÁGILES
METODOLOGÍAS ÁGILES
 
Programación extrema
Programación extremaProgramación extrema
Programación extrema
 
Fases en el desarrollo de un programa
Fases en el desarrollo de un programaFases en el desarrollo de un programa
Fases en el desarrollo de un programa
 
Fundamentos del diseño de software
Fundamentos del diseño de softwareFundamentos del diseño de software
Fundamentos del diseño de software
 
Modelo de desarrollo rapido de aplicaciones (5)
Modelo de desarrollo rapido de aplicaciones (5)Modelo de desarrollo rapido de aplicaciones (5)
Modelo de desarrollo rapido de aplicaciones (5)
 
Modelo de desarrollo rápido de aplicaciones (RAD)
Modelo de desarrollo rápido de aplicaciones (RAD)Modelo de desarrollo rápido de aplicaciones (RAD)
Modelo de desarrollo rápido de aplicaciones (RAD)
 
METODOLOGIAS AGILES
METODOLOGIAS AGILESMETODOLOGIAS AGILES
METODOLOGIAS AGILES
 
BDD TDD ATDD
BDD TDD ATDDBDD TDD ATDD
BDD TDD ATDD
 
UNIDAD_I.ppt
UNIDAD_I.pptUNIDAD_I.ppt
UNIDAD_I.ppt
 
Conferencia_Introducción a la Ingeniería de Software
Conferencia_Introducción a la Ingeniería de SoftwareConferencia_Introducción a la Ingeniería de Software
Conferencia_Introducción a la Ingeniería de Software
 
Díme que desarrollas y te diré que metodología usar
Díme que desarrollas y te diré que metodología usarDíme que desarrollas y te diré que metodología usar
Díme que desarrollas y te diré que metodología usar
 
Pracicas de Ingenieria de Software
Pracicas de Ingenieria de SoftwarePracicas de Ingenieria de Software
Pracicas de Ingenieria de Software
 
La Práctica : Una visión general
La Práctica : Una visión generalLa Práctica : Una visión general
La Práctica : Una visión general
 
La Práctica : Una visión general
La Práctica : Una visión generalLa Práctica : Una visión general
La Práctica : Una visión general
 
fundamentos teoricos ingenieria de softwaare
fundamentos teoricos ingenieria de softwaarefundamentos teoricos ingenieria de softwaare
fundamentos teoricos ingenieria de softwaare
 

(Behavior driven development (bdd ) [sólo lectura])

  • 1. Behavior Driven Development (BDD) Desarrollo Dirigido por Comportamiento Gestión de Sistemas Informatizados. Prof. Daniel Molina Cabrera Escuela Superior de Ingeniería - Universidad de Cádiz Raquel García García Inmaculada García Romero Virginia Serrano García
  • 2. Indice: 1. Introducción 2. Principios fundamentales 3. Ciclo de desarrollo BDD 4. Herramientas y frameworks de BDD
  • 3. 1. Introducción • Nace en 2003 de manos de Dan North como una evolución del pensamiento tras el Test Driven Development (TDD) y también tomando conceptos del Domain Driven Design (DDD). • Uniendo ambas ideas en un todo integrado que hace más evidente la relación entre estos dos caminos de desarrollo de software.
  • 4. 1. Introducción El desarrollo dirigido por comportamiento, o Behavior Driven Development (BDD) es una técnica de Desarrollo Agil De Software, esto es, una técnica de programación que cuestiona el comportamiento de una aplicación antes y durante el proceso de desarrollo. De esta forma, se fomenta la colaboración entre desarrolladores, testers, analistas y personas del negocio en un proyecto de software.
  • 5. 1. Introducción Mediante preguntas tales como: “¿Qué debería hacer esta aplicación?” o “¿Qué debería hacer esta parte?” , los desarrolladores pueden identificar brechas en la comprensión del problema del dominio y hablar con sus pares o expertos del dominio para encontrar las respuestas.
  • 6. 1. Introducción Los desarrolladores guiados por comportamiento usan su lenguaje nativo en combinación con el lenguaje ubicuo de DDD para describir el propósito y beneficios de su código. Esto les permite enfocarse en por qué el código debe ser creado, antes que en los detalles técnicos, y minimiza la traducción entre el lenguaje técnico en el cuál se escribe el código y el lenguaje de dominio hablado por las personas del negocio, usuarios, interesados, gerentes de proyecto, etc.
  • 7. 1. Introducción Objetivo: Contribuir a que el desarrollo de software se centre en la construcción de elementos, siguiendo una prioridad, que tengan un valor verificable para el negocio. BDD permite un entendimiento más global del sistema a crear, un entendimiento común de todos los involucrados y ayuda a eliminar malos entendidos sobre lo que el sistema debe hacer.
  • 8. 2. Principios fundamentales Suficiente es Suficiente: La planificación por adelantado, el análisis y el diseño tienen un rendimiento decreciente. No debemos hacer menos de lo que se necesita para empezar, pero más que eso es un esfuerzo inútil. Entregar valor a nuestros “stakeholders”: Si te encuentras haciendo algo que no entrega valor o incrementa tu habilidad/posibilidad de entregar valor, deja de hacerlo y haz algo distinto. Todo es comportamiento: Ya sea a nivel de código, de aplicación o más allá, podemos usar el mismo pensamiento y la misma lingüística para describir comportamiento a cualquier nivel de granularidad.
  • 9. 3. Ciclo de desarrollo BDD 1. Discusión. Desarrolladores, testers, expertos de dominio y el dueño de producto se juntan y discuten la historia, gradualmente descomponiendo y destilando el comportamiento en un conjunto de especificaciones simples. 2. Decisión. El dueño de producto decide cuando la especificación cumple suficientemente el comportamiento esperado y está de acuerdo con los casos de ejemplo y demostración de la historia y cierra el alcance de la misma. 3. Desarrollo. Los testers refinan los ejemplos de la especificación y los desarrolladores instrumentan las especificaciones creando primero pruebas que fallan y después implementando la funcionalidad. 4. Demostración. Una vez que todos los tests pasan la historia puede ser demostrada al dueño de producto.
  • 10. 4. Herramientas de BDD Concordion: es un framework Java de Software Libre que permite convertir especificaciones en texto común sobre requerimientos en pruebas automatizadas. JBehave: es un framework Java para mejorar la colaboración entre desarrolladores, QA, analistas de negocio, Dueño Del Producto y todos los miembros del equipo a través de escenarios automatizados y legibles.