Your SlideShare is downloading. ×
Taller de Unit Testing y TDD en Java: Parte 1
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Taller de Unit Testing y TDD en Java: Parte 1

5,793
views

Published on

Primera parte del taller de Unit Testing y TDD en Java, usando JUnit 4. El código para el taller está en https://github.com/janogonzalez/junit-lessons

Primera parte del taller de Unit Testing y TDD en Java, usando JUnit 4. El código para el taller está en https://github.com/janogonzalez/junit-lessons

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,793
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
77
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Taller de Unit Testingy TDD en JavaParte 1Jano GonzálezDesarrollador
  • 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)

×