Test-Driven Development Juan Carlos Olivares Rojas MSN: juancarlosolivares@hotmail.com jcolivar@itmorelia.edu.mx 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
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).
• Ejemplo
Test-Driven
Feature: Feature:Search Search In Inorder orderto tolearn learnmore more As Asan aninformation informationseeker seeker I Iwant wantto tofind findmore moreinformation informationwhen whenI Ineed needitit Scenario: Scenario:Find Findwhat whatI’I’looking lookingfor for Given GivenI Iam amon onthe theKvasir Kvasirsearch searchpage page When WhenI Isearch searchfor for“cucumber “cucumbergithub” github” Then ThenI Ishould shouldsee see “”” “”” Behavior BehaviorDriven DrivenDevelopment Development “”” “””
Test-Driven
• Los DSL aun no están estandarizados del todo se puede utilizar Cucumber junto con Groovy. Given Given/^I /^Iam amon onthe theKvasir Kvasirsearch searchpage$/ page$/do do visit(‘http://www.kvasir.mx/’) visit(‘http://www.kvasir.mx/’) end end When When/^I /^Isearch searchfor for“cucumber “cucumbergithub”$/ github”$/do do fill_in(‘q’, fill_in(‘q’,:with :with=> =>query) query) click_button(‘go’) click_button(‘go’) end end Then Then/^I /^Ishould shouldsee see$/ $/do do|text| |text| response_body.should response_body.shouldcontain(text) contain(text) end end
Test-Driven
• Java es actualmente multilenguaje.
una
plataforma
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
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.
多Preguntas?