Post on 13-Jan-2015
description
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)