Download Clase modelo

Test-Driven Development
Juan Carlos Olivares Rojas
MSN: [email protected]
[email protected]
http://antares.itmorelia.edu.mx/~jcolivar/
@jcolivares
Social Network: Facebook, LinkedIn. Hi5
Test-Driven
• 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
• Ejemplo
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
“””
Test-Driven
• Los DSL aun no están estandarizados del todo
se puede utilizar Cucumber junto con Groovy.
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
Test-Driven
• Java
es
actualmente
multilenguaje.
Java
Groovy
JRuby
Jython
una
Scala
plataforma
Clojure
Máquina Virtual Java
???
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
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.
¿Preguntas?