¿Debo incluir pruebas del sistema en un proyecto de primavera?

Question

Mi proyecto web de primavera consiste en:

1. Clases UTILES;
2. repositorios;
3. servicios;
4. controladores.

   Las pruebas son las siguientes:

   1. Pruebas de la unidad para las clases UTIL;
   2. Pruebas de integración de primavera para repositorios con HSQLDB;
   3. Pruebas de la unidad para servicios con repositorios simulados;
   4. Pruebas de unidad para controladores con servicios simulados.

      También puede haber pruebas del sistema que prueben la funcionalidad general del proyecto. Se puede realizar con una herramienta externa como selenio o se puede realizar utilizando pruebas de integración de resortes.

      La pregunta es, ¿debo incluir tales pruebas del sistema de integración de resortes en un proyecto o deberían separarse de alguna manera?

      Veo dos problemas sobre las pruebas del sistema en un proyecto: 1. Necesitan una afinación de configuración porque tales pruebas no se ejecutarán con la configuración de producción (por ejemplo, las pruebas necesitan un DataSource local, no el de JNDI); 2. No son autónomos, necesitan algunos recursos externos, etc. No puedo simplemente ejecutarlos como pruebas de unidad habituales.

      ¿Cómo organizas las pruebas de su sistema?

Answer 1

en pequeños proyectos que los he guardado en el mismo lugar. En los grandes proyectos empresariales (el tipo para el que puede aprovechar de manera útil, por ejemplo), por ejemplo, hemos organizado pruebas del sistema en un paquete / proyecto separado. Esto ayuda a mantenerlos separados de la base de código principal.

Si no hace esto, hay todo tipo de tentación de reutilizar clases del Código para "ayudar" en algo que debería centrarse más en la experiencia de los usuarios del sistema (un usuario puede ser otro sistema ). Si esto sucede, termina con el acoplamiento entre las clases de dominio del proyecto y la UI, que tendrá el efecto inevitable de la necesidad de duplicar gran parte de la lógica, lo que ayuda a mantenerlos desacoplados en la base de código real.

La mayoría de las veces, la lógica en los escenarios del sistema realmente se centrará en las páginas, pantallas, llamadas web, etc., por lo que reutilizar el código del proyecto principal es un arenque rojo. Mantenga los paquetes separados para evitar que esto suceda, y porque una vez que evite que suceda, no hay necesidad de tenerlos en el mismo lugar.

Do, sin embargo, asegúrese de que las pruebas del sistema se registren en el mismo control de la versión que el código.

Si no está haciendo una integración continua y pruebas / implementación, eso podría ser otra área para la cual algún aprendizaje lo ayudará con los archivos de configuración. Ese problema no desaparece solo porque tiene pruebas en un proyecto separado, desafortunadamente.