Test-Driven Development Juan Carlos Olivares Rojas MSN:

Presentación del tema: "Test-Driven Development Juan Carlos Olivares Rojas MSN:"— Transcripción de la presentación:

1 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

2 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

3 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

4 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

5 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

6 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

7 Ejemplo Test-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 “””

8 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

9 Java es actualmente una plataforma multilenguaje. Test-Driven Máquina Virtual Java Java GroovyJRubyJythonScalaClojure???

10 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

11 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

12 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

13 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

14 Concretar escribiendo criterios para los test de aceptación Probar/Implementar: Sí, primero las pruebas Entregar y evolucionar. Test-Driven

15 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

16 Para mejorar las historias de usuario se recomienda colocar ejemplo: Example Driven Development. Ejemplo: Test-Driven

17 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

18 ¿Preguntas?