Behavior Driven
Development
Repaso de TDD
•
Práctica de desarrollo de software propuesta por Kent Beck•
Parte de XP y de metodologías ágiles, pero puede ser usada también con cualquier otra metodologíaLas 3 reglas de Tío Bob
•
Las 3 reglas de Tío Bob Martin (@unclebobmartin) sobre TDD:!
1. No está permitido que escribas código para producción a menos que sea para hacer pasar un test unitario que falla.
2. No está permitido que escribas más de un test unitario que falle; y los fallos de compilación son fallos.
3. No está permitido que escribas más código para producción que el que sea suficiente para pasar un test unitario que falla.
“If you think about this you will realize that you simply cannot write very much code at all without compiling and executing something. Indeed, this is really the point. In everything we do, whether writing tests, writing production code, or refactoring, we
keep the system executing at all times. The time between running tests is on the order of seconds, or minutes. Even 10 minutes is too long.”
The Bowling Game Kata
•
Uncle Bob propone un ejemplo de aprendizaje que se ha hecho muy popular entre los practicantes de TDD: aprendizaje basado en Katas. Propone la Kata del Juego de Bolos.•
Prueba la Kata, repítela, memorízala. La preguntaremos en el examen. Al final interiorizas decisiones y empiezas a conseguir “sentido dediseño”.
•
Memoriza las secciones, repítelas•
El Primer Test•
El Segundo Test•
El Tercer Test•
El Cuarto TestPrerrequisitos para BDD
•
Para hacer bien BDD se supone que:•
Sabemos hacer tests unitarios (The Art of Unit Testing - proquest)•
Sabemos la técnica de TDD y todas las técnicas asociadas (mocks, inyección de dependencias, etc.) (TDD by example - proquest)•
Pero la técnica no es suficiente, hay que saber cómo usarla:•
Qué nombre poner a los tests para que sean legibles y mantenibles•
Cómo definir los tests para ampliar las características del proyecto y conseguir más valorNombrado correcto de los tests
•
Estilo tradicional (mal):! ! !
•
Usando “When” y “Should”:public class BankAccountTest {!
@Test!
public void testTransfer() {...}!
!
@Test!
public void testDeposit() {...}!
}
public class WhenTransferringInternationalFunds {!
@Test!
public void shouldTransferFundsToDestinationAccount() {...}!
!
@Test!
public void shouldDeductFeesAsSeparateTransation() {...}!
!
Escenarios
•
Estructura para definir criterios de aceptación y pruebas•
“Given” (condiciones previas)•
“When” (situación)•
“Then should” (resultado)Given a customer has a current account!
When the customer transfers funds from this account to an overseas account !
Then the funds should be deposited in the overseas account!
Especificaciones ejecutables
•
Al ser de muy alto nivel, las pruebas se convierten en especificaciones ejecutables•
Se definen a partir de los ejemplos y de los criterios de aceptación, en el lenguaje del modelo del dominio de negocio (siguiendo laspropuestas de Domain Driven Design charla de Eric Evans)
•
Sirven•
Para guiar el desarrollo de TDD y de la programación del sistema•
Documentación viva•
Ejemplos de uso•
La ejecución de las pruebas y de las especificaciones ejecutables se realiza de forma automática en la tubería de despliegueLenguajes
•
Las especificaciones son DSLs (Domain Specific Languages) que se traducen a frameworks de testing de más bajo nivel•
El framework más conocido es Cucumber, con implementación en más de40 idiomas y traducción a Ruby, Java, .Net, y muchos otros lenguajes
•
El lenguaje en el que se definen las especificaciones en Cucumber se llamaGherkin
Feature: Search courses!
Courses should be searchable by topic!
Search results should provide the course code! !
Scenario: Search by topic!
Given there are 240 courses which do not have the topic "biology"!
And there are 2 courses A001, B205 that each have "biology" as one of the topics!
When I search for "biology"!
Then I should see the following courses:!
| Course code |!
Building the right software right
•
Debemos conseguir:•
Software que funciona(building the software right)
•
Software que aporta valor(building the right software)
•
BDD integra las técnicas de TDD,automatización, continuous
delivery (building the software
right) junto con las de
retroalimentación frecuente,
desarrollo incremental (building
