introducción al testing unitario
TRANSCRIPT
Preguntas Frecuentes
¿Cómo pruebo un test que no devuelve nada?
public void tell_dont_ask_principle(params…)
@JuanmaGomeR
Preguntas Frecuentes
¿Cómo debo probar los métodos get/set?
public String getAlmuerzo() {return almuerzo;
}
public void setAlmuerzo(String…)@JuanmaGomeR
Preguntas Frecuentes
¿Cómo testear los métodos privados?
private Algo privateMethod(params…) {...}
@JuanmaGomeR
Preguntas Frecuentes
¿Cómo de simple es un método para decir que es demasiado
simple para testear?
@JuanmaGomeR
Preguntas Frecuentes
¿Cada cuanto tiempo ejecutar mis tests?
Cambio, commit, minuto, hora, día, año, década...
@JuanmaGomeR
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
Tests Unitarios
Deben ser independientes de los datos puesto que no probamos datos, sino
funcionalidad @JuanmaGomeR
Tests Unitarios
No se hacen uso de dependencias de la
clase a probarSi no, serían test de integración
@JuanmaGomeR
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
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
¿Cómo diseñar un test unitario?
Un test unitario es independiente de los demás y del entorno
@JuanmaGomeR
¿Cómo diseñar un test unitario?
Su éxito no depende del orden de ejecución
de los demás tests
@JuanmaGomeR
Algunas Buenas Prácticas
@Testpublic 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
Algunas Buenas Prácticas
Escribir un test cuando solamente sea
necesario. NO cobertura 100%
@JuanmaGomeR
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
Algunas Buenas Prácticas
Los tests están colocados en un lugar
representativo (mismo paquete, por ejemplo)
@JuanmaGomeR
Algunas Buenas Prácticas
@Testpublic 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
Algunas Buenas Prácticas
Fácilmente mantenibles y entendibles
Siguen siendo código fuente
@JuanmaGomeR
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
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