2012-03-01 18 views
11

Al usar la validación basada en anotaciones para un bean de formulario, ¿cuál es la mejor práctica para probar dichos beans para garantizar que se especifiquen las validaciones correctas? para cada campo?Buenos patrones para pruebas unitarias de beans que tienen validación basada en anotaciones en Spring MVC

Por ejemplo, si usted tiene:

public class MyForm { 
    @NotNull 
    private String name; 
} 

¿Cuál es la mejor manera de verificar que @NotNull se aplica a ella?

Una forma obvia es crear un validador, descartarlo y esperar que falle. Pero en mi opinión, esta no es la mejor manera, ya que probará el comportamiento y la implementación de @NotNull usando eso en lugar de confiar en el marco.

Idealmente, me gustaría utilizar la reflexión o una utilidad que me da la posibilidad de afirmar que una validación @NotNull (y cualquier otra) se aplica a un campo determinado, en lugar de tener que enviar varias combinaciones de valores que no validen .

¿Hay una forma elegante de hacerlo, o estoy en el camino correcto en general?

Respuesta

4

También puede escribir pruebas de unidades para sus beans que se anotan usando JSR303 usando la fábrica de validadores. Ver ejemplo: http://musingsofaprogrammingaddict.blogspot.com/2009/02/using-bean-validation-with-spring.html

+0

Gracias. El artículo principal en la publicación en realidad lo está haciendo de la manera que quiero evitar. Sin embargo, hay un comentario en esa publicación (de gunnar) que lo está haciendo de la manera en que esperaba, verificando la anotación en lugar del comportamiento de la anotación. –

+2

Agregue partes obligatorias del artículo vinculado como parte de su respuesta para evitar perder información si la página se desconecta. – CSchulz

5

Dos cosas que debe considerar:

NO probar su partido bibliotecas/marcos de terceros.

Debe confiar en ellos, se supone que ya han sido probados por sus responsables y el uso de la comunidad circundante. No los prueba, más bien evalúe ellos. Para asegurarse de que se ajusten a sus necesidades y mitiguen los riesgos.

¡El comportamiento de la prueba es lo que realmente importa!

En la gran mayoría de las aplicaciones hay poco lugar para la verdadera prueba de la unidad como la lógica de negocio es bien pequeña se han generalizado a través de múltiples módulos de la aplicación. Por lo tanto, debe considerar las pruebas de integración con la misma prioridad que las pruebas unitarias. Y esto se captura más fácilmente mediante el uso de un enfoque conductual.

Por lo tanto, para responder a su pregunta, no intente probar la unidad de un form bean en absoluto. Es solo un objeto de transporte. Lo que debe probar es cómo reacciona el receptor con esa forma, y ​​verifique tanto el caso normal como los casos extremos.

+2

no estoy de acuerdo con las pruebas bibliotecas de terceros, sin embargo, las pruebas de su configuración es tan importante como el comportamiento de la prueba. –

+0

Sí, ese es un buen punto y estoy de acuerdo con eso. Sin embargo, creo (como dice frant.hartm) que hay espacio para probar la configuración. Todo lo demás (es decir, la validación real) no tiene nada que ver directamente con el bean y no debería probarse aquí. –

+1

+1 por 'Por lo tanto, debe considerar las pruebas de integración con la misma prioridad que las pruebas unitarias.' – artbristol

2

Probamos las anotaciones en las propiedades del bean como parte de las pruebas de integración entre nuestra capa de presentación y envase de primavera.

lo que hacemos es crear MockPortletContext falso, DispatcherPortlet y MockRequests (estas clases son parte de la biblioteca de pruebas de la primavera), llenan las solicitudes para que se vean como forma real fue enviado y luego llamar al dispatcherPortlet. (tenemos el entorno de portlet pero no importa)

Luego puede verificar que su servidor se haya llamado apropiadamente o que la respuesta contenga un resultado vinculante con los errores de validación esperados que es lo que necesita.

2

Puede probarlo fácilmente.

Digamos que está utilizando Hibernate Validator. Más o menos, debería ser algo como esto

import javax.validation.ConstraintViolation; 
    import junit.framework.Assert; 
    import org.hibernate.validator.HibernateValidator; 
    import org.junit.Before; 
    import org.junit.Test; 
    import org.springframework.validation.beanvalidation.LocalValidatorFactoryBean; 

private LocalValidatorFactoryBean localValidatorFactory; 


@Before 
public void setup() { 
    localValidatorFactory = new LocalValidatorFactoryBean(); 
    localValidatorFactory.setProviderClass(HibernateValidator.class); 
    localValidatorFactory.afterPropertiesSet(); 
} 

    @Test 
    public void testNullValidationError() { 
     final MyForm myForm= new MyForm(); 
     myForm.setName(null); 
     Set<ConstraintViolation<MyForm >> constraintViolations =  localValidatorFactory.validate(myForm); 
     Assert.assertTrue("Your error message", constraintViolations.notNull == null); 
    } 
+0

No, esto es exactamente lo que quiero evitar en la prueba unitaria del bean, como se explica en la publicación original y en los seguimientos. –

Cuestiones relacionadas