¿Existe un marco de prueba de unidades 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 en el blog sobre el uso de la reflexión de Java para autoevaluar dichos métodos.

¿Alguna estructura (por ejemplo, jUnit) proporciona esa función? p.ej. Una anotación que dice "esta prueba T debe auto-probar todos los getters/setters en la clase C, porque afirmo que son estándar".

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

Answer 1

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

Answer 2

No tengo conocimiento de ninguna biblioteca o clase disponible que lo haga. Esto puede deberse principalmente a que no me importa, ya que estoy del lado de oponerme firmemente a tales pruebas. Así que, aunque usted pidió no debe ser un poco de justificación para este punto de vista:

dudo que autotesting captadores y definidores benefician la calidad de su código o su cobertura: Cualquiera de estos métodos se utilizan desde otro código (y probados allí, por ejemplo, 100% cubierto) o no se usa en absoluto (y podría eliminarse). Al final, dejarás getters y setters porque se usan desde la prueba pero en ningún otro lugar de la aplicación.

Debe ser fácil escribir tal prueba, p. con Apache Commons BeanUtils, pero dudo que realmente lo necesites si tienes buenas pruebas de lo contrario.

Answer 3

Voy a favorecer el diseño 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 son breaking encapsulation.

Answer 4

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 existe una precisión máxima en los valores de BigDecimal?

La prueba de unidad debe verificar si el comportamiento es correcto si hay valores no válidos. Esto no puede ser automatizado.

Si no tiene ninguna lógica en setter y getter, entonces debe usarse en cualquier lugar 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 comprador y el colocador. 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 5

Respondiendo al comentario anterior en @me aquí debido a mi reputación:

Vlookward, no escribir getters/setters no tiene sentido en absoluto. 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. Existe una lógica comercial 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 aplicación para la próxima interfaz puede ser totalmente genera automáticamente (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í prueba sólo lo que está escrito a mano. No importa si es un getter/setter.

Answer 6

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 debe evitar los métodos getter y setter tanto como sea posible, pero mientras estén cerca y se necesitan dos líneas para probarlos, es una buena cosa hacerlo.

Answer 7

I am trying out openpojo

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

1. Le permite verificar todos los pojo's en su proyecto.
2. Parece comprobar las mejores prácticas en POJO de

Comprobar este tutorial para un comienzo rápido Tutorial

Answer 8

creé el proyecto OpenPojo para resolver este problema exacta.

El proyecto le permite validar:

• cumplir estándar de codificación de Pojo (es decir, todos los campos privados, o ninguna variable nativos, etc ...)
• cumplir el comportamiento Pojo (es decir, setter valor que acaba, sin transformación, etc.)
• Validar Identidad Pojo (es decir,Uso de anotación igualdad & generación de código hash basado)

See Tutorial

Answer 9

I guess this library is the answer to your question

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 propiedad/valor predeterminado y no predeterminado.

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

Answer 10

No escribo casos de prueba para cada propiedad, sino que pruebo todos los setters/getters en un solo caso de prueba utilizando reflexión/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