java - tutorial - junit netbeans

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

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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 .

Answer 6

No escribo casos de prueba para cada propiedad, sino que pruebo todos los setters / getters en un solo caso de prueba usando reflection / introspector para determinar el tipo (s). Aquí hay un gran recurso que muestra esto:

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

Answer 7

Estoy probando openpojo

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

1. Le permite verificar todos los Pojo en su proyecto.
2. Parece verificar las mejores prácticas en pojo

Consulte este tutorial para un inicio rápido Tutorial

Answer 8

Supongo que esta biblioteca es la respuesta a tu pregunta

prueba todos los valores iniciales del bean, los setters , los getters , hashCode(), equals() and toString() . Todo lo que tiene que hacer es definir un mapa de propiedad / valor predeterminado y no predeterminado.

También puede probar objetos que son beans con constructores adicionales no predeterminados.

Answer 9

Creé el proyecto OpenPojo para resolver este problema exacto .

El proyecto te permite validar:

• Aplicar el estándar de codificación Pojo (es decir, todos los campos son privados, o no hay variables nativas, etc.)
• Hacer cumplir el comportamiento de Pojo (es decir, el colocador hace la configuración JUSTA, sin transformación, etc.)
• Valide la identidad de Pojo (es decir, use la anotación basada en la anotación y la generación de hashcode)

Ver Tutorial

Answer 10

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.