Test-Driven Development

Juan Carlos Olivares Rojas

MSN: juancarlosolivares@hotmail.comjcolivar@itmorelia.edu.mx

http://antares.itmorelia.edu.mx/~jcolivar/@jcolivares

Social Network: Facebook, LinkedIn. Hi5

• Escribir una clase de test de forma conjunta a la clase que queremos implementar nos ayuda a pensar en los requisitos que deben cumplir los métodos antes de escribirlos.

• Un test unitario es además la mejor documentación que podemos dar a una clase, no solo muestra como se espera que se use, si no que además puede ejecutarse.

Test-Driven

• Mientras que los documentos de texto suelen quedar rápidamente obsoletos un test siempre estará actualizado.

• Corregir un fallo durante la fase de aceptación del producto cuesta varias veces más que corregirlo durante la fase de desarrollo.

Test-Driven

• Solo hay 3 reglas:

• No se permite escribir código de producción al menos que sea con el objetivo de escribir una prueba que esta fallando.

• No se permite escribir más código de prueba del que sea necesario para que la prueba falle.

Test-Driven

• No se permite escribir más código de producción del que es suficiente para pasar la prueba que falla.

• TDD realmente funciona pero: • Es muy difícil de hacer TDD de manera

correcta.

• Muchos terminan conformándose con hacer pruebas unitarias, pero no TDD.

Test-Driven

• TDD no es una técnica de prueba!!!• Es una técnica de diseño y construcción

• BDD es una técnica de diseño y codificación que integra tanto pruebas unitarias como de aceptación.

• Tiene un enfoque desde fuera hacia a dentro. Utiliza un DSL (Lenguaje de Dominio Específico).

Test-Driven

• EjemploTest-Driven

Feature: Search In order to learn more As an information seeker I want to find more information when I need it

Scenario: Find what I’ looking for Given I am on the Kvasir search page When I search for “cucumber github” Then I should see “”” Behavior Driven Development “””

Feature: Search In order to learn more As an information seeker I want to find more information when I need it

Scenario: Find what I’ looking for Given I am on the Kvasir search page When I search for “cucumber github” Then I should see “”” Behavior Driven Development “””

• Los DSL aun no están estandarizados del todo se puede utilizar Cucumber junto con Groovy.

Test-Driven

Given /^I am on the Kvasir search page$/ do visit(‘http://www.kvasir.mx/’) end

When /^I search for “cucumber github”$/ do fill_in(‘q’, :with => query) click_button(‘go’) end Then /^I should see $/ do |text| response_body.should contain(text) end

Given /^I am on the Kvasir search page$/ do visit(‘http://www.kvasir.mx/’) end

When /^I search for “cucumber github”$/ do fill_in(‘q’, :with => query) click_button(‘go’) end Then /^I should see $/ do |text| response_body.should contain(text) end

• Java es actualmente una plataforma multilenguaje.

Test-Driven

• Razones por las que no se hacen testing:

• El código es demasiado difícil de testear.

• El desarrollo de los test está despriorizado y no forma parte integral del proceso de desarrollo.

• Los programadores no quieren escribir test.

Test-Driven

• Para la realización de pruebas unitarias en muchos casos se recomienda el uso de “mock”

• Los mocks son objetos simulados muy parecidos a los “crash dummies” en pruebas de auto.

• Los mocks se utilizan en “pruebas sintéticas” cuando el objeto real no puede emplearse o es sumamente complejo.

Test-Driven

• Un ejemplo de mock podría darse en pruebas de integración: un módulo depende de datos proporcionados por la interfaz que aun no está disponible.

• Otro ejemplo podría ser el acceder a datos que se encuentran en una base de datos. Para fines prácticos se manejan desde un archivo o bien de manera directa.

• Un mock implementa las mismas funcionalidades que un objeto real.

Test-Driven

• Los mocks pueden catalogarse como “Fake” cuando devuelven un arreglo de respuestas predeterminadas.

• En general el ciclo de desarrollo se recomienda que sea:

• Escuchar al cliente

• Transcribir los requisitos en historias de usuario

Test-Driven

• Concretar escribiendo criterios para los test de aceptación

• Probar/Implementar: Sí, primero las pruebas

• Entregar y evolucionar.

Test-Driven

• Para realizar las pruebas se realiza el siguiente ciclo repetitivo:

• Agregar un test• Correr el test y ver las fallas• Escribir código• Correr de nuevo y ver que todas las

pruebas pasen• Refactorizar

Test-Driven

• Para mejorar las historias de usuario se recomienda colocar ejemplo: Example Driven Development.

• Ejemplo:

Test-Driven

• Con este enfoque ya sabemos lo que quiere el cliente, por lo tanto ya podemos construir el software adecuado.

• No se implementa lo que no será usado.

• Minimizamos errores.

• Está diseñado para cambiar.

Test-Driven

¿Preguntas?