¿Existe un marco de prueba de unidad de Java que autoevalúe getters y setters?

votos
33

Existe un debate bien conocido en Java (y en otras comunidades, estoy seguro) si se deben probar los métodos triviales getter / setter. Por lo general, esto es con respecto a la cobertura del código. Aceptemos que este es un debate abierto, y no intentemos responderlo aquí.

Ha habido varias publicaciones de blog sobre el uso de la reflexión de Java para autoevaluar dichos métodos.

¿Algún marco (por ejemplo, jUnit) proporciona esa característica? Por ejemplo, una anotación que dice esta prueba T debe autoevaluar todos los getters / setters en la clase C, porque afirmo que son estándar.

Me parece que agregaría valor, y si fuera configurable, el debate se dejaría como una opción para el usuario.

Publicado el 20/09/2008 a las 17:43
fuente por usuario
En otros idiomas...                            


10 respuestas

votos
15

No estoy al tanto de ninguna biblioteca o clase disponible que haga esto. Esto puede deberse principalmente a que no me importa, ya que estoy del lado de oponerme firmemente a tales pruebas. Entonces, aunque hayas preguntado, debe haber un poco de justificación para esta vista:

Dudo que los get y setters automáticos beneficien la calidad de su código o su cobertura: O estos métodos se usan desde otro código (y se prueban allí, por ejemplo, 100% cubiertos) o no se usan en absoluto (y podrían eliminarse). Al final, dejarás getters y setters porque se usan desde la prueba pero en ningún otro lugar de la aplicación.

Debería ser fácil escribir una prueba de este tipo, por ejemplo, con Apache Commons BeanUtils, pero dudo que realmente lo necesites si tienes buenas pruebas de lo contrario.

Respondida el 20/09/2008 a las 17:50
fuente por usuario

votos
11

He creado el OpenPojo proyecto para la solución de este exacto problema.

El proyecto le permite validar:

  • Hacer cumplir estándar de codificación de Pojo (es decir, todos los campos privados, o ninguna variable nativos, etc ...)
  • Hacer cumplir el comportamiento Pojo (es decir colocador se limita a establecer, ninguna transformación, etc.)
  • Validar Pojo Identidad (es decir, uso de anotación basado en la igualdad y la generación de código hash)

ver Tutorial

Respondida el 25/02/2011 a las 20:36
fuente por usuario

votos
7

Unitils hace esto con el método estático assertRefEquals.

Respondida el 21/09/2008 a las 01:19
fuente por usuario

votos
7

En la mayoría de los casos, setter y getter hacen más como única configuración y obtienen un campo interno. Un objeto tiene que verificar las reglas internas que solo contienen valores válidos. Por ejemplo

  • ¿son posibles los valores nulos?
  • ¿Son posibles las cadenas vacías?
  • o valores negativos?
  • o un valor cero?
  • o los valores de una lista son válidos?
  • o hay un valor máximo?
  • o hay una precisión máxima en los valores de BigDecimal?

La prueba unitaria debe verificar si el comportamiento es correcto si hay valores inválidos. Esto no puede ser automatizado.

Si no tiene lógica en el setter y getter, entonces debe usarse en cualquier parte de su aplicación. Escriba una prueba donde su objeto sea un parámetro para una prueba más compleja. Puede probarlo con diferentes valores de la lista.

Pon a prueba tu lógica de negocio y no el getter y el setter. El resultado también debería incluir una cobertura de getter y setter. Los métodos deben ser cualquier resultado en su lógica de negocio también si solo tiene una biblioteca pública. Si el captador y el colocador no tienen cobertura de código, entonces quítelo.

Respondida el 20/09/2008 a las 19:47
fuente por usuario

votos
5

He hecho algo así. Una clase java simple que toma un objeto y prueba todos los getters y métodos setter. http://sourceforge.net/projects/getterandsetter/

Creo que debes evitar los métodos getter y setter tanto como sea posible, pero mientras estén disponibles y se necesiten dos líneas para probarlos, es una buena idea hacerlo.

Respondida el 25/10/2008 a las 22:02
fuente por usuario

votos
2

Voy a favorecer el diseño de OO sobre la cobertura del código, y ver si no puedo mover esos campos a la clase que los necesita. Así que trataré de ver si esos captadores y establecedores se pueden eliminar, como se sugirió anteriormente. getters y setters están rompiendo la encapsulación .

Respondida el 20/09/2008 a las 18:07
fuente por usuario

votos
1

Creo que esta biblioteca es la respuesta a su pregunta

pone a prueba todos los valores iniciales del frijol, el setters, la getters, hashCode(), equals() and toString(). Todo lo que tiene que hacer es definir un mapa de defecto y no por defecto de propiedad / valor.

También puede probar los objetos que son granos con constructores adicionales no por defecto.

Respondida el 04/03/2011 a las 22:02
fuente por usuario

votos
1

Estoy probando openpojo

He pateado los neumáticos y parece que hacer el trabajo.

  1. Se le permite comprobar todos los años POJO en su proyecto.
  2. Parece comprobar las mejores prácticas en materia de POJO

Compruebe este tutorial para un inicio rápido tutorial

Respondida el 04/02/2011 a las 20:13
fuente por usuario

votos
0

No escribo casos de prueba para cada propiedad, pero en lugar de evaluar todas las setters / captadores en un solo caso de prueba utilizando la reflexión / introspector para determinar el tipo (s). Aquí es un gran recurso que muestra esto:

http://www.nearinfinity.com/blogs/scott_leberknight/do_you_unit_test_getters.html

Respondida el 20/07/2011 a las 15:07
fuente por usuario

votos
0

Respondiendo el comentario anterior en @me aquí por mi reputación:

Vlookward, no escribiendo getters / setters no tiene ningún sentido. Las únicas opciones para establecer campos privados es tener definidores explícitos, establecerlos en su constructor o establecerlos indirectamente a través de otros métodos (difiriendo funcionalmente al colocador a otro lugar). ¿Por qué no usar setters?

Bueno, a veces, no hay necesidad de que el campo sea privado (lo siento si mi inglés no es muy bueno). A menudo, escribimos nuestro software ya que era una biblioteca y encapsulamos nuestros campos (nuestros campos de lógica de negocios) con getters / setters innecesarios.

Otras veces, esos métodos son realmente necesarios. Entonces, hay dos posibilidades:
1. Hay lógica de negocios dentro de ellos. Entonces podrían probarse, pero no son verdaderos captores / incubadores. Siempre escribo esa lógica en otras clases. Y las pruebas prueban que otras clases, no el POJO .
2. No hay. Entonces, no los escriba a mano, si puede. Por ejemplo, una implementación para la próxima interfaz puede autogenerarse por completo (¡y también en tiempo de ejecución!):

interface NamedAndObservable {
  String getName();
  void setName(String name);
  void addPropertyChangeListener(PropertyChangeListener listener);
  void addPropertyChangeListener(String propertyName,
                                 PropertyChangeListener listener);
}

Así que prueba solo lo que está escrito a mano. No importa si es un getter / setter.

Respondida el 22/09/2008 a las 11:23
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more