XP: Test Driven Development

Introducción
1. Problemas del testing
2. TDD no es una técnica de pruebas
  1. Es una técnica de diseño y codificación
Tipos de test
1. Tests de aceptación
  1. Prueban que el software cumpla con un requisito de negocio
  2. Usan GUI
2. Tests funcionales
  1. Subconjunto de los tests de aceptación
  2. Prueban una funcionalidad con valor de negocio
3. Tests de sistema
  1. Mayor de los tests de integración
  2. Puede ir de extremo a extremo
4. Tests de integración
  1. Integra más de un componente
5. Tests unitarios
  1. Lo más importantes para TDD
  2. Características
    1. Atómico
    2. Independiene
    3. Inocuo
    4. Rápido
Tests unitarios
1. "Any program feature without an automated test simply doesn’t exist." - Kent Beck
2. Testing realizado por desarrolladores durante la construcción del código
3. Testing de componentes o testing de clases aisladas
4. Formas
  1. Usando métodos main() y verificando el resultado
  2. Ejecutando la aplicación y verificando el resultado
  3. Debugging
5. xUnit
  1. Java: JUnit
    1. JUnit 3.x
      1. Extender TestCase
      2. Sobrescribir setUp()
      3. Hacer métodos que comiencen con test
      4. Usar assertEquals() para verificar la salida
    2. JUnit 4.x
      1. No es necesario heredar
      2. Anotar los métodos con @Test
      3. Usar assertEquals() para verificar la salida
  2. .NET: NUnit
  3. Python: PyUnit
  4. Ruby: RubyUnit
  5. Perl: PerlUnit
  6. C++: CppUnit
  7. PHP: PHPUnit
Prácticas
1. Test First Development
  1. Pasos
2. Refactoring
  1. Cambios en la estructura interna del código
  2. Sin cambios en su comportamiento externo
Ciclo de desarrollo
1. Escribir la prueba
2. Escribir el código haciendo que pase la prueba
3. Ejecutar las pruebas automatizadas
4. Repetición
1. Rojo - Verde - Refactor
Beneficios
1. La implementación de las funciones justas que el cliente necesita y no más
2. La minimización del número de defectos que llegan al software en fase de producción.
3. La producción de software modular, altamente reutilizable y preparado para el cambio.
4. El código es testeable, fue construido para serlo
5. El test es testeado, lo vimos fallar al inicio
6. Los tests son ejecutables
7. Los tests documentan el código
8. Tenemos el diseño suficiente para hacer pasar los tests
Referencias
1. Ble C, Diseño Ágil con TDD
2. http://opensourcetesting.org
3. http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
4. http://junit.org
Acerca de
1. Topic
2. Topic