2008-09-01 10 views
14

He desarrollado algunas clases con un comportamiento similar, todas implementan la misma interfaz. Implementé una fábrica que crea el objeto apropiado y devuelve la interfaz. Estoy escribiendo una prueba unitaria para la fábrica. Todo lo que obtienes es una interfaz para el objeto. ¿Cuál es la mejor manera de probar que la fábrica ha funcionado correctamente?Comprobación de los resultados de una fábrica en una prueba de unidad

Me gustaría saber la respuesta en Java, pero si hay una solución que cruza idiomas me gustaría saberlo.

Número 2. en la respuesta, ¿se haría como la otra respuesta? Si es así, marcaré la otra respuesta aceptada también y volveré a redactar mi pregunta para dirigirte a una fábrica donde se devuelve una interfaz y no tienes idea de qué tipo de clase concreta implementó la interfaz, y el caso en el que sabes qué clase concreta era usado.

Respuesta

16

Dado que no sé cómo su método de fábrica se parece, todo lo que puedo aconsejar en este momento es

  1. Comprobar para ver el objeto es la aplicación concreta correcta que buscas:

    IMyInterface fromFactory = factory.create(...); 
    Assert.assertTrue(fromFactory instanceof MyInterfaceImpl1); 
    
  2. Puede comprobar si la configuración de fábrica de las instancias concretas con variables de instancia válidas.

0
if (myNewObject instanceof CorrectClass) 
{ 
    /* pass test */ 
} 

actualización:

No sabe por qué esto quedó marcada hacia abajo, así que voy a ampliar un poco ...

public void doTest() 
{ 
    MyInterface inst = MyFactory.createAppropriateObject(); 
    if (! inst instanceof ExpectedConcreteClass) 
    { 
     /* FAIL */ 
    } 
} 
+4

Se marcó abajo porque debe usar Aserción en lugar de una prueba ... – Nicolas

0

@ CEM-catikkas Creo que sería más correcto comparar los valores getClass(). GetName(). En el caso de que la clase MyInterfaceImpl1 esté subclase, su prueba podría romperse, ya que la subclase es instancia de MyInterfaceImpl1. Me gustaría volver a escribir de la siguiente manera:

IMyInterface fromFactory = factory.create(...); 
Assert.assertEquals(fromFactory.getClass().getName(), MyInterfaceImpl1.class.getName()); 

Si usted piensa que esto podría fallar de alguna manera (no puedo imaginar), hacer que las dos verificaciones.

+0

Estoy de acuerdo, pero no creo que verifique la igualdad de los nombres de clase es redundante. Solo consultar las clases debería ser lo suficientemente bueno. –

+1

¿Por qué probarías que un método de Class devuelve un valor igual, en lugar de simplemente comparar los objetos de la clase? – jdmichal

20

Lo que estamos tratando de hacer no es la Unidad de Pruebas

Si el resultado si los objetos devueltos son instancias de clases concretas específicas, usted no es prueba de la unidad. Eres una prueba de integración. Si bien las pruebas de integración son importantes, no es lo mismo.

En las pruebas unitarias, solo necesita probar el objeto en sí. Si afirma en el tipo concreto de los objetos abstractos devueltos, está probando la implementación del objeto devuelto.

pruebas unitarias de los objetos en general

Cuando la unidad de pruebas, hay cuatro cosas, que desea hacer valer:

  1. valores de retorno de consultas (métodos no vacíos) son lo que les espera a ser.
  2. Los efectos secundarios de los comandos (métodos de vacío) modifican el objeto como se espera.
  3. Se reciben los comandos que se envían a otros objetos (esto generalmente se hace usando simulaciones).

Además, solo desea probar lo que se puede observar desde una instancia de objeto, es decir, la interfaz pública. De lo contrario, te vinculas a un conjunto específico de detalles de implementación. Esto requeriría que cambies tus pruebas cuando cambien esos detalles.

fábricas Prueba de la unidad

Unidad de prueba en fábricas es realmente interesante, porque usted no está interesado en el comportamiento de los objetos devueltos de consultas. Ese comportamiento (afortunadamente) se prueba en otro lugar, presumiblemente mientras se prueba el objeto por sí mismo. Sólo está realmente interesado en si el objeto devuelto tiene o no el tipo correcto , que está garantizado si su programa se compila.

Como las fábricas no cambian con el tiempo (porque entonces serían "Constructores", que es otro patrón), no hay comandos para probar.

Las fábricas son responsables de crear instancias de los objetos, por lo que no deben depender de otras fábricas para hacer esto por ellos. Ellos pueden depender de un Constructor, pero aún así, no se supone que podamos probar la corrección del Constructor, solo si el Constructor recibe el mensaje o no.

Esto significa que todo lo que tiene que probar en Factories es si envían o no los mensajes a los objetos de los que dependen. Si usa Inyección de Dependencia, esto es casi trivial. Solo fíjate en las dependencias en las pruebas de tu unidad y verifica que reciban los mensajes.

Resumen de las fábricas de prueba Unidad

  1. No probar el comportamiento ni los detalles de implementación de los objetos devueltos! ¡Su fábrica no es responsable de la implementación de las instancias de objetos!
  2. Compruebe si los comandos enviados a las dependencias se reciben o no.

Eso es todo. Si no hay dependencias, no hay nada que probar. Excepto tal vez para afirmar que el objeto devuelto no es una referencia null.

fábricas pruebas de integración

Si usted tiene un requisito de que el tipo de objeto abstracto devuelto es una instancia de un tipo específico concreto, entonces esto cae bajo las pruebas de integración.

Otros aquí ya han respondido cómo hacerlo utilizando el operador instanceof.

+0

Además, aquí hay una gran charla sobre pruebas unitarias de Sandi Metz: https://www.youtube.com/watch?v=URSWYvyc42M – Undreren

+0

Cómo probar la unidad y luego "Se reciben los comandos enviados a otros objetos" para el objeto construido de fábrica ¿sí mismo? Digamos que factory does devuelve 'new SomeObject (someDependency)'.Esto es en realidad una pieza de lógica y no es tan comprobable como el constructor de burlas, incluso si es posible con algunos marcos de prueba, es más bien un "no no". – topr

+0

@topr Esa pieza de lógica debe probarse en las pruebas propias de la clase devuelta, no a través de la fábrica. – Undreren

Cuestiones relacionadas