¿Existe un marco de prueba unitaria de Java que pruebe automáticamente los captadores y definidores?[cerrado]

StackOverflow https://stackoverflow.com/questions/108692

  •  01-07-2019
  •  | 
  •  

Pregunta

Existe un debate bien conocido en Java (y en otras comunidades, estoy seguro) sobre si se deben probar o no los métodos triviales de obtención/definición.Por lo general, esto se refiere a la cobertura del código.Acordemos 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 probar automáticamente dichos métodos.

¿Algún marco (p. ej.jUnit) proporciona tal característica?p.ej.Una anotación que dice "esta prueba T debería probar automáticamente todos los captadores/definidores en la clase C, porque afirmo que son estándar".

Me parece que aportaría valor, y si fuera configurable, el 'debate' quedaría como opción al usuario.

¿Fue útil?

Solución

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

Otros consejos

No conozco 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 preguntaste allí debe Habría un poco de justificación para esta opinión:

Dudo que los captadores y definidores de pruebas automáticas beneficien la calidad de su código o su cobertura:Estos métodos se utilizan desde otro código (y se prueban allí, p. ej.100 % cubierto) o no utilizado en absoluto (y podría eliminarse).Al final, dejarás los captadores y definidores porque se usan en la prueba pero en ningún otro lugar de la aplicación.

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

Yo creé el AbrirPojo proyecto para resolver esto exacto problema.

El proyecto permite validar:

  • Hacer cumplir el estándar de codificación Pojo (es decir,Todos los campos privados, o sin variables nativas, etc.)
  • Hacer cumplir el comportamiento de Pojo (es decir,setter hace SÓLO configuración, sin transformación, etc.)
  • Validar la identidad de Pojo (es decir,Utilice igualdad basada en anotaciones y generación de código hash)

Ver Tutorial

En la mayoría de los casos, setter y getter hacen más que solo configurar y obtener un campo interno.Un Objeto tiene que verificar las reglas internas para que solo contenga valores válidos.Por ejemplo

  • ¿Son posibles los valores nulos?
  • ¿Son posibles 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 BigDecimal?

La prueba unitaria debe verificar si el comportamiento es correcto si hay valores no válidos.Esto no se puede automatizar.

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

Pruebe su lógica de negocios y no el captador y definidor.El resultado también debe cubrir el captador y el definidor.Los métodos deben tener cualquier resultado en su lógica de negocios incluso si solo tiene una biblioteca pública.Si el captador y el definidor no tienen cobertura de código, entonces elimínelo.

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

Creo que deberías evitar los métodos getter y setter tanto como sea posible, pero mientras existan y se necesiten dos líneas para probarlos, es bueno hacerlo.

Preferiré el diseño OO a la cobertura de código y veré si no puedo mover esos campos a la clase que los necesita.Así que intentaría ver si esos captadores y definidores se pueden eliminar, como se sugirió anteriormente.Los captadores y definidores son romper la encapsulación.

Supongo que esta biblioteca es la respuesta a tu pregunta.

prueba todos los valores iniciales del frijol, el setters, el 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.

Estoy probando openpojo

He pateado los neumáticos y parece que funciona.

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

Consulte este tutorial para un inicio rápidoTutorial

Respondiendo al comentario anterior en @a mí aquí por mi reputación:

Mirando hacia adelante, no escribir captadores/definidores no tiene ningún sentido.Las únicas opciones para configurar campos privados es tener configuradores explícitos, configurarlos en su constructor o configurarlos indirectamente a través de otros métodos (diferiendo funcionalmente el configurador a otro lugar).¿Por qué no utilizar definidores?

Bueno, a veces no es necesario que el campo sea privado (lo siento si mi inglés no es muy bueno).A menudo, escribimos nuestro software como si fuera una biblioteca y encapsulamos nuestros campos (nuestros campos de lógica de negocios) con captadores/definidores innecesarios.

Otras veces, esos métodos son realmente necesarios.Entonces, hay dos posibilidades:
1.Hay una lógica empresarial dentro de ellos.Entonces deberían ser probados, pero no son verdaderos captadores/definidores.Siempre escribo esa lógica en otras clases.Y las pruebas prueban que otras clases, no la POJO.
2.No hay.Luego, si puedes, no los escribas a mano.Por ejemplo, una implementación para la siguiente interfaz puede generarse completamente 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í que prueba sólo lo que esté escrito a mano.No importa si es un captador/definidor.

No escribo casos de prueba para cada propiedad, sino que pruebo todos los establecedores/obtenedores en un solo caso de prueba usando reflexión/introspector para determinar los tipos.Aquí hay un gran recurso que muestra esto:

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

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top