Pruebas de JUnit para POJOs

Question

Trabajo en un proyecto en el que tenemos que crear pruebas unitarias para todos nuestros beans simples (POJO). ¿Tiene algún sentido crear una prueba unitaria para POJOs si todo lo que incluyen son getters y setters? ¿Es una suposición segura suponer que los POJO funcionarán aproximadamente el 100% del tiempo?

---

duplicado de - Should @Entity Pojos be tested?

Ver también

Is it bad practice to run tests on a DB instead of on fake repositories?

Is there a Java unit-test framework that auto-tests getters and setters?

Answer 1

La regla en TDD es "Test everything that could possibly break" ¿Se puede romper un getter? Generalmente no, así que no me molesto en probarlo. Además, el código I do prueba ciertamente llamará al getter para que se pruebe.

Mi regla personal es que escribiré una prueba para cualquier función que tome una decisión, o que haga un cálculo más que trivial. No escribiré una prueba para i+1, pero probablemente lo haré para if (i<0)... y definitivamente lo hará para (-b + Math.sqrt(b*b - 4*a*c))/(2*a).

Por cierto, el énfasis en POJO tiene un motivo diferente. Queremos que la gran cantidad de nuestro código escrito en POJOs que no dependa del entorno que se ejecutan en. Por ejemplo, es difícil probar los servlets, ya que dependen de la ejecución dentro de un contenedor. Por lo tanto, queremos que los servlets llamen a POJO que no dependen de su entorno y, por lo tanto, son fáciles de probar.

Answer 2

POJOs pueden contener también otras funciones, tales como equals(), hashCode(), compareTo() y varias otras funciones. Puede ser útil saber que esas funciones funcionan correctamente.

Answer 3

No creo que haya un punto para probar getters y setters simples de propiedades. El objetivo de las pruebas unitarias no es verificar que tu compilador funcione.

Sin embargo, tan pronto como agrega un comportamiento condicional, nulo o de otro tipo a sus getters y setters (u otros métodos), creo que es apropiado agregar pruebas unitarias.

Answer 4

Creo que si los getters y los setters se han creado usando un IDE, entonces debería estar bien. Tenemos otras cosas para poner nuestro código. Obviamente, probarías los POJO para la serialización/deserialización.

Answer 5

Mi respuesta es que los captadores y establecedores triviales no merecen sus propias pruebas. Si agrego cualquier código que no sea simple de lectura o escritura, entonces agrego pruebas.

Por supuesto, esto es todo un texto estándar, por lo que podría escribir fácilmente un script que genere pruebas de unidad para sus captadores y decodificadores, si cree que tiene algún valor. Ciertos IDEs pueden permitirle definir una plantilla que cree casos de prueba con métodos de prueba completados para este código repetitivo (estoy pensando en IntelliJ aquí, pero Eclipse probablemente también pueda manejarlo, aunque no he hecho nada como esto en ninguno de los dos; IDE).

Answer 6

En mi experiencia, la creación de pruebas unitarias para POJO con solo getters y setters, es exagerado. Hay algunas excepciones, por supuesto, si hay una lógica adicional en getter/setter como comprobar nulo y hacer algo especial, entonces crearía una prueba unitaria para eso.

Además, si hay un error en el POJO crearía una prueba de unidad para que podamos evitar que vuelva a suceder.

Answer 7

probablemente vale la pena una prueba sencilla para asegurarse de que no haya escrito

public void setX(int x) { 
    x = x; 
} 

A pesar de que debería estar codificando para evitar que (por poner un modificador final en el parámetro del método, o similar). También depende de cómo está generando sus accesores, y si podrían sufrir errores de copiar/pegar, etc. (esto ocurrirá incluso en entornos que intentan imponer el uso de IDE, simplemente lo hará).

Mi principal preocupación con las clases que contienen muchos setters/getters, sin embargo, es ¿Qué hace la clase? Los objetos deberían hacer cosas por usted, en lugar de simplemente retener y devolver datos. Si se trata de objetos de entidad de datos, entonces el patrón setter/getter puede ser correcto.Sin embargo, el mejor patrón es establecer los datos en el objeto, y pedirle al objeto que haga cosas con él (calcule su saldo bancario, ejecute el cohete, etc.) en lugar de devolver los datos y ¡deje que lo haga usted mismo!

Answer 8

Unidad Código de prueba que desea saber funciona (para las situaciones probadas, por supuesto). No pruebes el código de unidad que solo quieres que esté seguro de que funciona.

No puedo pensar en mucho de lo que solo quiera estar seguro.

Answer 9

Una vez pasé dos horas a causa de algo como esto:

int getX() 
{ 
    return (x); 
} 

int getY() 
{ 
    return (x); // oops 
} 

Dado que lleva muy poco tiempo para escribir las pruebas para captadores sencillos, lo hago ahora por costumbre.

Answer 10

Estoy experimentando con cobatura para la cobertura de código y me encontré con el mismo problema.

Sería bueno tener una anotación para agregar a la clase que dice no incluir esta clase en la cobertura del código. Sin embargo, es posible poner sus pojo en un paquete separado y luego excluir ese paquete del análisis.

Consulte la documentación en función de su herramienta, funciona con Ant, Maven o la línea de comandos.

Answer 11

Uso IntelliJ como un IDE, y prácticamente escribe POJO's triviales para mí, sin duda el constructor y getters/settors. No veo ningún punto en la prueba de unidades, ya que es muy probable que haya errores en el código de prueba que escribo.

Answer 12

Acabo de iniciar un proyecto para hacer esto. está en etapa pre-alfa en este momento. Es un plugin de Eclipse.

Si bien estoy de acuerdo en que un POJO setter/getter no necesariamente necesita una prueba, creo que es bueno tener la prueba simple allí porque como las cosas cambian con el tiempo, le será más fácil agregar más pruebas para los POJO's La prueba de la unidad está configurada, los métodos están ahí para probar el setter/getter, todo lo que tienes que hacer es manejar la nueva complejidad.

Esto también ayuda con los informes de cobertura de código, lo que ayuda a mantener contentos a los gerentes. (Mi compañía usa Emma).

https://sourceforge.net/projects/unittestgplugin/

Answer 13

Las pruebas unitarias no sólo validan que el código funciona correctamente, pero que documentan el comportamiento esperado.No sé cuántas veces he visto cosas que se rompen porque en algún momento, alguien cambia el comportamiento de un getter o setter en un POJO y luego inesperadamente rompe algo más (por ejemplo, alguien agrega lógica al setter) que si alguien establece un valor nulo en una cadena, el colocador lo cambia a una cadena vacía para que los NPE no sucedan).

No veo las pruebas unitarias en los almacenes de datos POJO como una pérdida de tiempo, los veo como una red de seguridad para el mantenimiento futuro. Dicho esto, si está escribiendo pruebas manualmente para validar estos objetos, lo está haciendo de la manera difícil. Eche un vistazo a algo como http://gtcgroup.com/testutil.html

Answer 14

Hay una utilidad de código abierto http://meanbean.sourceforge.net/ que le permite probar los POJO. También hay una página que describe los méritos/preguntas que uno podría tener sobre lo que ofrece esta utilidad y por qué debería usarse.

Nunca me he cansado (todavía), pero me lo han recomendado.

Answer 15

1. BIBLIOTECA DE USO: utilice las bibliotecas existentes que ayudan a probar POJO. Una de esas bibliotecas que encontré es meanbean.

   Ref: http://meanbean.sourceforge.net/

   Maven: http://mvnrepository.com/artifact/org.meanbean/meanbean (versión actual: 2.0.3)

2. IGNORE POJOs: Sonar se puede configurar para excluir POJOs o paquetes específicos que deben excluirse de unidad- informes de cobertura de prueba. Algunos ejemplos a continuación:

   <properties> 
       <sonar.coverage.exclusions> 
        **/domain/**/*, 
        **/pojos/* 
       </sonar.coverage.exclusions> 
   </properties> 
   

Answer 16

Este problema se puede resolver mediante el uso de la biblioteca de Lombok que elimina todo este código repetitivo, así como los iguales y código hash.

Así que no es necesario para poner a prueba a menos que tenga un requisito específico para los iguales y hashCode

https://projectlombok.org/