Test Driven Development (TDD)

Get Started. It's Free
or sign up with your email address
Test Driven Development (TDD) by Mind Map: Test Driven Development (TDD)

1. ¿Qué es?

1.1. Es un estilo de programar

1.2. Esta formado por tres actividades principales que son:

1.2.1. Programar

1.2.2. Hacer pruebas

1.2.3. Diseñar (Mejorar código)

1.3. Es una forma de pensar en sus requerimientos o diseño antes de escribir código funcional

1.4. « Nos preocupamos más por el "qué" y el "por qué", antes del "cómo"»

2. ¿Cuáles son las reglas a seguir para hacer TDD?

2.1. Escribe una sola prueba unitaria que describa un aspecto del programa

2.2. Corre la prueba, que debe fallar porque el programa carece de esa funcionalidad

2.3. Escribe solo el código necesario, lo más simple posible, para pasar la prueba

2.4. Refactoriza el código hasta dar con el criterio más simple

2.5. Repite, acumulando pruebas unitarias a través del tiempo

3. Tropezones comunes

3.1. Individuales

3.1.1. Olvidar correr las pruebas frecuentemente

3.1.2. Escribir muchas pruebas de una sola vez

3.1.3. Escribir pruebas que son muy largas o cubren demasiados aspectos

3.1.4. Escribir pruebas demasiado triviales, por ejemplo omitiendo afirmaciones

3.1.5. escribiendo pruebas para código trivial, por ejemplo los get/set

3.2. Del equipo

3.2.1. Adopción parcial — solo unos pocos desarrolladores en el equipo lo usan

3.2.2. Pobre mantenimiento de las suites de pruebas – Comunmente lleva a suites de priebas con tiempos de ejecución demasiado grandes

3.2.3. Suite de pruebas abandonadas (rara vez usadas o nunca usadas) – Algunas veces por su pobre rendimiento como resultado de pobre mantenimiento, otras veces como resultado de cambios en el equipo de desarrollo.

4. Beneficios de usar TDD

4.1. Se reduce la tasa de errores, con un incremento moderado al costo de desarrollo inicial del proyecto.

4.2. Los esfuerzos iniciales invertidos son compensados luego, en las etapas finales del proyecto.

4.3. Programadores experimentados reportan que practicar TDD lleva a mejorar cualidades en la calidad del diseño del código y lleva a un mayor grado de calidad técnica, por ejemplo mejorando los indicadores de cohesión y acoplamiento.

4.4. Te permite dar pequeños pasos en el desarrollo de software, que es más productivo que dar grandes pasos.

5. Fuentes

5.1. What is Test Driven Development (TDD)?

5.2. Code coverage - Wikipedia

5.3. Introduction to Test Driven Development (TDD)

6. Signos de uso

6.1. Un alto nivel de "code coverage" no garantiza el apropiado uso de TDD.

6.1.1. Code Coverage es una medida (porcentual) en las pruebas de software que mide el grado en que el código fuente de un programa ha sido comprobado.

6.2. Un nivel bajo de "code coverage" (menor a 80%) es un indicador probable de deficiencias en el dominio de TDD de parte del equipo

6.3. Los registros del control de versiones deberán mostrar que las pruebas de código fueron realizadas cada vez que el código fue realizado, en proporciones similares.

7. Niveles de habilidad

7.1. Principiantes

7.1.1. Tiene la capacidad de escribir una prueba unitaria previo a escribir el correspondiente código.

7.1.2. able to write code sufficient to make a failing test pass

7.2. Intermedio

7.2.1. practices “test driven bug fixing”: when a defect is found, writes a test exposing the defect before correction

7.2.2. able to decompose a compound program feature into a sequence of several unit tests to be written

7.2.3. knows and can name a number of tactics to guide the writing of tests (for instance “when testing a recursive algorithm, first write a test for the recursion terminating case”)

7.2.4. able to factor out reusable elements from existing unit tests, yielding situation-specific testing tools

7.3. Experto

7.3.1. able to formulate a “roadmap” of planned unit tests for a macroscopic features (and to revise it as necessary)

7.3.2. able to “test drive” a variety of design paradigms: object-oriented, functional, event-drive

7.3.3. able to “test drive” a variety of technical domains: computation, user interfaces, persistent data access…

8. Limitaciones de usar TDD

8.1. La cantidad de tiempo que toma comenzar a usar TDD es grande al inicio.

8.2. TDD puede tomar bastante tiempo al refactorizar el código, escribir nuevas pruebas y así por cada pequeño error.

8.3. TDD es difícil de implementar en proyectos de mantenimiento donde el tipo de trabajo son micro-errores, pequeñas mejoras y todo eso.

8.4. TDD es difícil de implementar cuando los requerimientos no son claros al inicio pero luego son aclarados gradualmente. En este caso se vuelve dificil para los desarrolladores y el QA obtener los resultados esperados en las pruebas.

9. Recursos para aprendizaje

9.1. Libros

9.1.1. Test Driven Development: By Example, by Kent Beck

9.1.2. Test Driven

9.1.3. BDD in Action, Second Edition

9.2. Guías & Artículos

9.2.1. Qué es y cómo funciona TDD: Desarrollo a partir de las pruebas, no al revés

9.2.2. Javascript

9.2.2.1. A Gentle Introduction to Javascript Test Driven Development: Part 1

9.2.2.2. Learning JavaScript Test-Driven Development by Example — SitePoint

9.2.3. Visual studio

9.2.3.1. Visual Studio: Test-driven development walkthrough

9.3. Cursos

9.3.1. Free Test Driven Development Tutorial - Introduction to TDD in C#

9.3.2. TDD in C# From A to Z

10. ¿Cuál es el ciclo de desarrollo en TDD?

10.1. Escribe una prueba que falla. Escribe el código para que pase. Optimiza y limpia el código.

11. Niveles de TDD

11.1. Developer TDD

11.1.1. Escribes una única prueba de desarrollador y luego solo el código de producción suficiente para completar esa prueba. El objetivo del TDD a nivel desarrollador es especificar un diseño detallado y ejecutable para su solución sobre una base JIT

11.1.2. Comunmente solo se le llama TDD

11.2. Acceptance TDD

11.2.1. Escribes una única prueba de aceptación o una especificación de comportamiento, y luego el código de producción suficiente para completar esa prueba. El objetivo de ATDD es especificar los requisitos detallados y ejecutables para su solución en tiempo de ejecución

11.2.2. Comunmente se le llama ATDD o BDD (Behavior Driven Development)