1. Desarrollo impulsado por el comportamiento (BDD):
el desarrollo impulsado por el comportamiento (BDD) es una técnica de desarrollo que se enfoca más en el comportamiento de una aplicación de software. Principalmente crea una especificación ejecutable que falla porque la característica respectiva no existe, luego escribe el código más simple que puede hacer que la especificación pase y como resultado obtenemos el comportamiento requerido implementado en el sistema. En realidad, es una metodología de equipo en la que están involucrados Desarrolladores, Clientes y QA.
Proceso de BDD:
- Escribe el comportamiento de la aplicación.
- Escribir los scripts automatizados
- Luego implemente el código funcional.
- Verifique si el comportamiento es exitoso y si no es así, arréglelo
- Organizar el código (Opcional)
- Repita los pasos para otro comportamiento.
2. Desarrollo dirigido por pruebas (TDD):
el desarrollo dirigido por pruebas (TDD) es una técnica de desarrollo que se enfoca más en la implementación de una característica de una aplicación/producto de software. Principalmente se refiere a escribir un caso de prueba que falla porque la funcionalidad especificada no existe y luego actualizar el código que puede hacer que el caso de prueba pase y como resultado obtenemos la función implementada en el sistema. En realidad, es una práctica de desarrollo en la que los desarrolladores están involucrados.
Proceso de TDD:
- Agregar caso de prueba
- Ejecute los casos de prueba y observe cómo falla la prueba
- Actualizar el código
- Vuelva a ejecutar los casos de prueba
- Refactorizar el código (Opcional)
- Repita los pasos para otro caso de prueba
Diferencia entre BDD y TDD:
S. NO. |
Desarrollo impulsado por el comportamiento |
Desarrollo basado en pruebas |
01. | El desarrollo impulsado por el comportamiento es una técnica de desarrollo que se centra más en el comportamiento de una aplicación de software. | Test Driven Development es una técnica de desarrollo que se enfoca más en la implementación de una característica de una aplicación/producto de software. |
02 | En BDD los participantes son Desarrolladores, Clientes, QAs. | En TDD los participantes son desarrolladores. |
03. | Principalmente crea una especificación ejecutable que falla porque la característica respectiva no existe, luego escribe el código más simple que puede hacer que la especificación pase y como resultado obtenemos el comportamiento requerido implementado en el sistema. | Principalmente se refiere a escribir un caso de prueba que falla porque la funcionalidad especificada no existe y luego actualizar el código que puede hacer que el caso de prueba pase y como resultado obtenemos la función implementada en el sistema. |
04. | Su enfoque principal está en los requisitos del sistema. | Su enfoque principal está en la prueba unitaria. |
05. | En BDD el punto de partida es un escenario. | En TDD el punto de partida es un caso de prueba. |
06 | Es una metodología de equipo. | Es una práctica de desarrollo. |
07 | Aquí, el lenguaje utilizado para escribir comportamientos/escenarios es un lenguaje inglés simple. | Aquí se usa un lenguaje similar al que se usa para el desarrollo de funciones como lenguaje de programación. |
08 | En BDD se requiere la colaboración entre todos los actores. | En TDD se requiere colaboración solo entre los desarrolladores. |
09 | Es un buen enfoque para el desarrollo de proyectos impulsados por las acciones de los usuarios. | Es un buen enfoque para proyectos que involucran API y herramientas de terceros. |
10 | Algunas de las herramientas utilizadas son Cucumber, Dave, JBehave, Spec Flow, Concordian, BeanSpec, etc. | Algunas de las herramientas utilizadas son JBehave, JDave, Cucumber, Spec Flow, BeanSpec, FitNesse, etc. |
Publicación traducida automáticamente
Artículo escrito por Satyabrata_Jena y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA