método de prueba junit para getters & setters

Question

Tengo muchos beans Java en mi proyecto. Necesito generar una clase JUnit Test para ellos. Los métodos de prueba generados usando Eclipse 3.2 & JUnit 4.4 aspecto como el siguiente:

public void testGetName() { 
     // fail("Not yet implemented"); 
    } 

    @Test 
    public void testSetName() { 
     // fail("Not yet implemented"); 
    } 

    @Test 
    public void testGetEmployeeid() { 
     // fail("Not yet implemented"); 
    } 

    @Test 
    public void testSetEmployeeid() { 
     // fail("Not yet implemented"); 
    } 

algunos de mis frijoles tienen más de 100 campos ...

¿Hay un camino por el cual puedo obtener una sola prueba método para ambos getters & setters como testEmployeeid(), testName() para que en estos métodos pueda probar mis setters & getters en lugar de usar 2 diff. métodos de prueba para ellos ...

¿Cómo debo configurar eclipse para hacer esto?

Answer 1

La filosofía de Test Driven Development dice "prueba todo lo que pueda romperse". Es decir, enfoca tus esfuerzos en las pruebas útiles, en lugar de escribir pruebas por el simple hecho de hacerlo.

Los getters y setters son casi siempre un código trivial, que no vale la pena probar por sí mismos.

Sé que esta no es una respuesta directa a su súplica, pero pensé que aún podría ayudar señalar esto ;-) Entonces, ¿por qué realmente necesita escribir pruebas para todos los captadores y establecedores en primer lugar?

Answer 2

tal vez podría utilizar 'BeanUtils' Apache Commons para ayudar a automatizar esto:

http://commons.apache.org/beanutils/apidocs/org/apache/commons/beanutils/PropertyUtils.html#getSimpleProperty%28java.lang.Object,java.lang.String%29

Por ejemplo, hay un método describe(Object bean) que devolverá un mapa de todos los atributos de lectura mecánica (es decir, getter).

A continuación, recorra ese mapa y llamar a:

setSimpleProperty(Object bean, String name, Object value) 

y

public static Object getSimpleProperty(Object bean, String name) 

Y aunque estoy de acuerdo con el otro cartel que getters/setters son bastante trivial - Creo que es todavía vale la pena probarlos - para eliminar errores tipográficos, probar detectores de cambio de propiedad, etc.

Por ejemplo, esto extraerá dinámicamente los captadores de un frijol:

import java.io.Serializable; 
import java.util.Set; 
import org.apache.commons.beanutils.PropertyUtils; 

public class MyTestBean implements Serializable { 
    private int a; 
    private int b; 
    private int c; 
    private String x; 
    private String y; 
    private String z; 

    public static void main(String[] args) throws Exception { 
    MyTestBean bean=new MyTestBean(); 
    Set prop=PropertyUtils.describe(bean).keySet(); 
    for (Object o : prop) { 
     System.out.println((String)o); 
    } 
    } 

    public int getA() { 
     return a; 
    } 
    public void setA(int a) { 
     this.a = a; 
    } 
    public int getB() { 
     return b; 
    } 
    public void setB(int b) { 
     this.b = b; 
    } 
    public int getC() { 
     return c; 
    } 
    public void setC(int c) { 
     this.c = c; 
    } 
    public String getX() { 
     return x; 
    } 
    public void setX(String x) { 
     this.x = x; 
    } 
    public String getY() { 
     return y; 
    } 
    public void setY(String y) { 
     this.y = y; 
    } 
    public String getZ() { 
     return z; 
    } 
    public void setZ(String z) { 
     this.z = z; 
    }} 

Deberá descargar tanto BeanUtils como CommonsLogging y los JAR de ambas bibliotecas en su proyecto para ejecutar este código.

Answer 3

Si tiene 100 campos en una clase (con los correspondientes setters/getters) sospecho que su modelo de objeto no está descompuesto correctamente. Más de 100 campos suenan como una cantidad extraordinaria de campos para un objeto, y supongo que tiene varias responsabilidades que se pueden dividir entre una serie de objetos más especializados.

Answer 4

supongo que esta biblioteca es la respuesta a su pregunta: http://outsidemybox.github.com/testUtils/

pone a prueba todos los valores del frijol iniciales, los emisores, los captadores, hashCode(), es igual a() y toString(). Todo lo que tiene que hacer es definir un mapa de propiedad/valor predeterminado y no predeterminado.

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