Test-Driven Development
Juan Carlos Olivares Rojas
MSN: [email protected]@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?
Top Related