Introducción al testing unitario

  • 166 views
Uploaded on

Tips y buenas prácticas sobre testing unitario. Introducc

Tips y buenas prácticas sobre testing unitario. Introducc

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
166
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
3
Comments
0
Likes
0

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. Introducción al Testing Unitario @JuanmaGomeR
  • 2. Preguntas Frecuentes ¿Cómo pruebo un test que no devuelve nada? public void tell_dont_ask_principle(params…) @JuanmaGomeR
  • 3. Preguntas Frecuentes ¿Cómo debo probar los métodos get/set? public String getAlmuerzo() { return almuerzo; } public void setAlmuerzo(String…) @JuanmaGomeR
  • 4. Preguntas Frecuentes ¿Dónde colocar mis test? Carpeta, paquete... @JuanmaGomeR
  • 5. Preguntas Frecuentes ¿Cómo testear los métodos privados? private Algo privateMethod(params…) {...} @JuanmaGomeR
  • 6. Preguntas Frecuentes ¿Cómo de simple es un método para decir que es demasiado simple para testear? @JuanmaGomeR
  • 7. Preguntas Frecuentes ¿Cada cuanto tiempo ejecutar mis tests? Cambio, commit, minuto, hora, día, año, década... @JuanmaGomeR
  • 8. Testing Unitario Claves del test unitario @JuanmaGomeR
  • 9. Tests Unitarios Prueban una funcionalidad concreta @JuanmaGomeR
  • 10. Tests Unitarios Se basan en el principio de responsabilidad única: cada método tiene una única responsabilidad, y esa responsabilidad es la que pruebo @JuanmaGomeR
  • 11. Tests Unitarios Deben ser independientes de los datos puesto que no probamos datos, sino funcionalidad @JuanmaGomeR
  • 12. Tests Unitarios Son repetibles en el tiempo @JuanmaGomeR
  • 13. Tests Unitarios Sólo prueban los métodos públicos del SUT (System Under Test) @JuanmaGomeR
  • 14. Tests Unitarios No se hacen uso de dependencias de la clase a probar Si no, serían test de integración @JuanmaGomeR
  • 15. Otros tests ● Integración: prueban la conexión entre componentes. Debería ser el siguiente paso al test unitario. ● Funcionales: prueban la integración de todos los componentes que desarrollan una funcionalidad. ● Regresión: prueban que los SUT siguen funcionando a lo largo del tiempo (IC) ● Carga: prueban la eficiencia del código @JuanmaGomeR
  • 16. Testing Unitario ¿Cómo diseñar un test unitario? @JuanmaGomeR
  • 17. System Under Test (SUT) ● Es el sistema que vamos a probar. ● Probamos los métodos públicos: ○ Interface de nuestro SUT al mundo exterior ● ¿Los métodos privados no? ○ Relocalizar en otra parte del SUT o del sistema ○ PrivilegedAccessor @JuanmaGomeR
  • 18. ¿Cómo diseñar un test unitario? Un test unitario es independiente de los demás y del entorno @JuanmaGomeR
  • 19. ¿Cómo diseñar un test unitario? Ejecución extremadamente rápida @JuanmaGomeR
  • 20. ¿Cómo diseñar un test unitario? Su éxito no depende del orden de ejecución de los demás tests @JuanmaGomeR
  • 21. ¿Cómo diseñar un test unitario? Son repetibles en el tiempo @JuanmaGomeR
  • 22. ¿Cómo diseñar un test unitario? Se deben pueden ejecutar de forma automática @JuanmaGomeR
  • 23. Testing Unitario Algunas Buenas Prácticas @JuanmaGomeR
  • 24. Algunas Buenas Prácticas @Test public void pruebo_un_metodo_get() { String mi_dato = “Mi Dato”; MiObjeto mi_objeto = new MiObjeto(); mi_objeto.set_mi_dato(mi_dato); assertEquals(mi_dato, mi_objeto.get_mi_dato()); } @JuanmaGomeR
  • 25. Algunas Buenas Prácticas Escribir un test cuando solamente sea necesario. NO cobertura 100% @JuanmaGomeR
  • 26. Algunas Buenas Prácticas package es.miempresa.programa.producto.paquete public class MiObjeto { package String que_eres() { return “Soy tu objeto”; } } package es.miempresa.programa.producto.tests.paquete public class MiObjetoTests { @Test public void si_te_pregunto_devuelves_soy_tu_objeto() { assertEquals(“Soy tu objeto”, new MiObjeto().que_eres()); } } @JuanmaGomeR
  • 27. Algunas Buenas Prácticas Los tests están colocados en un lugar representativo (mismo paquete, por ejemplo) @JuanmaGomeR
  • 28. Algunas Buenas Prácticas @Test public void test_metodo1() { String a = “soy tu objeto”; String b = “soy otra cadena”; String c = null; int num = (a==b); if(num) { c=b; } assertEquals(a, new Agenda().getCamandulo(). getB()); @JuanmaGomeR }
  • 29. Algunas Buenas Prácticas Fácilmente mantenibles y entendibles Siguen siendo código fuente @JuanmaGomeR
  • 30. Algunas Buenas Prácticas Prueban el qué y no el cómo ○ Métodos públicos --> Qué ○ Métodos privados o protegidos --> Cómo  @JuanmaGomeR
  • 31. Algunas Buenas Prácticas Test única funcionalidad: No If, while, for, ... dentro de un test unitario Principio de responsabilidad única también para los tests @JuanmaGomeR
  • 32. ¡MUCHAS GRACIAS! @JuanmaGomeR