Taller de Unit Testingy TDD en JavaParte 1

Jano GonzálezDesarrollador

Parte 1

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

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

Parte N

● Si les interesa podemos hacer más talleres...

¡A practicar!

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

Lección 0

(cl.continuum.junit.lessons.Lesson0)

● Creando un test con la anotación @Test● assertEquals(expected, actual)

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)

Lección 2

(cl.continuum.junit.lessons.Lesson2)

● @Before, @After, @BeforeClass, @AfterClass

Lección 3

(cl.continuum.junit.lessons.Lesson3)

● assertThat(actual, matcher)

Ahora un poco de teoría

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.

¿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!

Qué probar

● Caso correcto● Caso erróneo● Casos de borde● Lanzamiento de excepciones

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

Un buen test

● Independiente● Repetible● Automatizado

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.

¡A practicar nuevamente!

Lección 4

● Hello TDD!

Otro poco de teoría

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

Feedback,Feedback,Feedback!

¿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

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

Ojo, oreja, pestaña y ceja:La agilidad es un medio, no un fin

(el fin es crear software de calidad)