Introducción a Behaviour Driven Development

1,2,3 Probando Acercando BDD a las masas Ricardo Markiewicz <gazer.arg@gmail.com>

Evolución

¿Por qué “testear”? ● Confianza – Manual – Automático

¿Por qué automatizar? ● Confianza – Test de regresión ● Refactoring – Agilidad al cambio Se pueden escribir test antes o después, ambos dan el mismo nivel de confianza

Test Driven Development ● Plantea escribir Test, luego código ● Desarrollo evolutivo ● El diseño emerge durante el desarrollo – No hay diseño previo ● Tiende al desastre en la mayoría de los casos :)

El problema de TDD ● TDD != escribir los tests primeros ● TDD =~ escribir los test primeros ● TDD no es acerca de escribir tests ● TDD es acerca de diseño ● TDD es una metodología de diseño, no de pruebas.

Behaviour Driven Development ● Hacer TDD y entender de que se trata cada cosa es difícil ● BDD ayudar a centrar el desarrollo – Verificable con valor empresarial – Lenguaje común entre el cliente y los desarrolladores ● BDD es una reformulación de las buenas prácticas existentes, no se trata de un nuevo punto de partida radical.

Proceso BDD ● Relevamiento de características a realizar. – Se habla con el cliente ● Se escriben historias de la forma Como Role Como un cliente, quiero sacar Quiero Feature dinero del cajero automático, de De modo que Benefit modo que no necesite pasar tiempo en la cola. ● Beneficios : El cliente entiende que es lo que se va a desarrollar ● Criterio de aceptación ejecutable

Historias ● Una historia luego se desglosa en diferentes escenarios. ● Cada escenario define una acción especifica para cumplir con la característica pactada. ● El escenario se describe en lenguaje coloquial, por lo que el cliente lo entiende, describiendo los pasos para lograrlo.

Historia : Sumas algebraicas Caracteristica: Sumas algebraicas Como un estudiante quiero sumar números de modo que el resultado en mis exámenes sea correcto. Escenario: Suma de dos números positivos Dado que tengo una calculadora Cuando sumo “2” y “2” Entonces debo ver “4”

BDD Cicle ● Doble red-green- refactor ● Primero historias ● Despues tests específicos

Cucumber : History Runner ● Intérprete de Historias hecho en Ruby ● Permite definir qué significa a nivel de programa cada frase de un escenario Dado /^que tengo una calculadora$/ do @calc = Calc.new end Cuando /^sumo “(d)” y “(d)”$/ do |n1, n2| @calc.sumar(n1, n2) end Entonces /^debo ver “(d)”$/ do |expected| @calc.result.should == expected end

Lo que deben estar pensando ● Estuve 2 días para implementar un simple método ● Mi capacidad de producción está por el piso ● ¡No llego nunca a la fecha de entrega!

Lo que deberían saber ● BDD es un proceso de desarrollo de software : hay que aprenderlo y madurarlo, así como una vez aprendimos a programar en objetos ● Facilidad para pautar metas con los clientes – Si se que hago 1 features por día, y tengo que hacer 20 features, tardo 20 días :) ● Buena documentación de como se usa el código escrito ● Código en constantes evolución, nunca hay retroceso

Herramientas ● Existen para Java, .NET, Ruby, Python, C, C++, AS3, Delphi, javascript, Scala, PHP ● Sitios – http://en.wikipedia.org/wiki/Behavior_Driven_Developme – http://www.behaviour-driven.org

Muchas Gracias ¿Preguntas? Ricardo Markiewicz <gazer.arg@gmail.com> http://www.twitter.com/gazer_arg/ http://www.gazer.com.ar/

Introducción a Behaviour Driven Development

by Ricardo Markiewicz on May 24, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 10

Statistics

Introducción a Behaviour Driven Development — Presentation Transcript