Este documento presenta una introducción a unit testing y TDD en Java. La sesión se dividirá en varias partes, comenzando con una demostración práctica de JUnit y matchers básicos, seguida de más detalles sobre otros matchers, mock objects y ejemplos de TDD. El documento también incluye enlaces a lecciones de código de ejemplo para practicar diferentes aspectos de testing unitario.

1. Taller de Unit Testing
y TDD en Java
Parte 1
Jano González
Desarrollador

2. Parte 1
● Iremos desde la práctica hacia la teoría:
● Uso de JUnit 4
● Matchers básicos
● Ejemplo simple (demasiado?) de TDD

3. Parte 2
● Próximo L&B
● Iremos desde la práctica hacia la teoría:
● Otros matchers
● Mock objects
● Ejemplo de TDD
● Cómo hacer buenos tests

4. Parte N
● Si les interesa podemos hacer más talleres...

5. ¡A practicar!

6. https://github.com/janogonzalez
/junit-lessons

7. Lección 0
(cl.continuum.junit.lessons.Lesson0)
● Creando un test con la anotación @Test
● assertEquals(expected, actual)

8. Lección 1
(cl.continuum.junit.lessons.Lesson1)
● assertEquals(expected, actual)
● assertArrayEquals(expecteds, actuals)
● assertTrue(condition)
● assertFalse(condition)
● assertNull(object)
● assertNotNull(object)
● assertSame(expected, actual)
● assertNotSame(expected, actual)

9. Lección 2
(cl.continuum.junit.lessons.Lesson2)
● @Before, @After, @BeforeClass,
@AfterClass

10. Lección 3
(cl.continuum.junit.lessons.Lesson3)
● assertThat(actual, matcher)

11. Ahora un poco de teoría

12. Unit Testing
● Tip para quedar como experto en testing: SUT
es System Under Test, es decir el sistema que
estamos probando.
● En un test unitario el SUT es la clase en forma
aislada.
● Los tests unitarios prueban los métodos
públicos de una clase.

13. ¿Unit? Testing
● Si al probar la clase esta hace uso de sus
dependencias entonces estamos haciendo un
test de integración → Yo le digo test de
componente.
● Para tener un test “verdaderamente” unitario
las dependencias de la clase deben ser mocks
→ Próxima semana.
● OJO: ¡Los tests de integración también son
buenos!

14. Qué probar
● Caso correcto
● Caso erróneo
● Casos de borde
● Lanzamiento de excepciones

15. Los peores tests posibles
● Uno que depende del orden de ejecución
● Uno que no es repetible
Un gatito muerte cada vez que alguien crea o
ejecuta uno de esos tests

16. Un buen test
● Independiente
● Repetible
● Automatizado

17. Buen diseño por default
● Cuando hacemos unit testing...
● Nuestras clases tienden a la alta cohesión y al bajo
acoplamiento → En forma automágica :)
● Nuestros métodos tienden a hacer una cosa y bien.
● Por lo general el código de buena calidad es
fácil de probar.

18. ¡A practicar nuevamente!

19. Lección 4
● Hello TDD!

20. Otro poco de teoría

21. El ciclo de desarrollo
● Hasta tener la funcionalidad lista
● Crear test que falla
● Implementar método
● Pasar el test
● Cuando la funcionalidad ya está lista
● Correr todos los tests
● Subir a control de versiones

22. Feedback,
Feedback,
Feedback!

23. ¿Por qué usar TDD?
● Me obliga a hacerme preguntas sobre los
requerimientos
● Me obliga en forma inconsciente a utilizar las
mejores prácticas de desarrollo
● Cuando hacemos los tests al final, estamos
mentalmente predispuestos a probar sólo lo
que va a funcionar

24. Mitos
● TDD es la única forma de hacer software de
calidad
● Es muy difícil el cambio de paradigma
● Es muy fácil el cambio de paradigma

25. Ojo, oreja, pestaña y ceja:
La agilidad es un medio, no un fin
(el fin es crear software de calidad)