2010-03-30 11 views
37

¿Es posible ejecutar pruebas JUnit desde dentro de mi aplicación java?¿Cómo ejecuto las pruebas JUnit desde dentro de mi aplicación java?

¿Hay marcos de prueba que pueda usar (como JUnit.jar?), O ¿me obligo a encontrar los archivos de prueba, invocar los métodos y rastrear las excepciones por mi cuenta?

La razón por la que pregunto es que mi aplicación requiere mucho trabajo para iniciar el lanzamiento (muchas dependencias y configuraciones, etc.) y el uso de una herramienta de prueba externa (como la tarea JUnit Ant) requeriría mucho trabajo para establecer arriba.

Es más fácil iniciar la aplicación y luego dentro de la aplicación ejecutar mis pruebas.

¿Existe un marco de prueba fácil que ejecuta pruebas y resultados de salida desde dentro de una aplicación java o me veo forzado a escribir mi propio marco?

+0

Puede burlarse de sus recursos o lo que sea, ejecutar la prueba en la aplicación Java no tiene sentido para mí .. eche un vistazo a la jmock.org – ant

Respuesta

74

Sí, puede hacerlo. Lo hice un par de veces para ejecutar pruebas de diagnóstico/humo en los sistemas de producción.Este es un fragmento de una parte clave de la JUnit invocando código:

JUnitCore junit = new JUnitCore(); 
Result result = junit.run(testClasses); 

NO use JUnit.main dentro de su aplicación, se invoca System.exit después de las pruebas están terminadas y por lo tanto se puede detener el proceso de JVM.

Es posible que desee capturar la salida de consola "regular" de JUnit (los puntos y el informe simple). Esto se puede hacer fácilmente registrando TextListener (esta clase proporciona este informe simple).

favor también ser consciente de varias complicaciones que utilizan este tipo de método:

  1. Prueba de cualquier "marco de pruebas", incluyendo uno tan pequeño, aunque es bastante simple puede ser confuso. Por ejemplo, si desea probar si el resultado de la falla de retorno del "marco de prueba" cuando falla una de las pruebas, podría (¿debería?) Crear una prueba JUnit de muestra que siempre falla y ejecutar esa prueba con el "marco de prueba". En este caso, el caso de prueba fallido es en realidad datos de prueba y no debe ejecutarse como JUnit "normal". Para ver un ejemplo de tales pruebas, puede consultar los casos de prueba interna de JUnit.

  2. Si desea preparar/mostrar su informe personalizado, debería registrar su propio RunListener, porque el resultado devuelto por JUnit no contiene información (directamente) sobre las pruebas aprobadas y el método de prueba (solo está "codificado" como una parte de la prueba Description).

+0

Esto es impresionante. Intento que se ejecute un conjunto de pruebas de JUnit automatizado en un servidor web personalizado, por lo que puedo configurar algunos cronjobs para lanzar pruebas unitarias e informar los resultados cada noche; esto es exactamente lo que esperaba encontrar. –

+1

A continuación se muestra el código para iniciar JUnit en su main y tener el resultado básico en la salida estándar: 'JUnitCore junitCore = new JUnitCore(); junit.addListener (new TextListener (System.out)); junit.run ( .class); 'Disculpa por el formato, pero es lo mejor que puedo hacer en un comentario. :) – RobMcZag

11

tal como se documenta en el JUnit FAQ:

public static void main(String args[]) { 
    org.junit.runner.JUnitCore.main("junitfaq.SimpleTest"); 
} 
10

La razón por la que pido es mi solicitud requiere mucho trabajo a lanzamiento inicio (un montón de dependencias y configuraciones, etc.) y el uso de una herramienta de prueba externa (como JUnit Ant tarea) requeriría mucho trabajo para configurar .

Debe eliminar estas dependencias del código que está probando. Las dependencias y las configuraciones son precisamente lo que intenta evitar al escribir un marco de prueba. Para cada prueba, debe orientarse a la parte más pequeña comprobable de una aplicación.

Por ejemplo, si necesita una conexión de base de datos para ejecutar algún proceso en una clase que está tratando de probar - desacople el objeto de manejo de la base de datos de su clase, páselo mediante un constructor o método setter, y en su uso de prueba una herramienta como JMock (o escribir una clase de stub) para construir un objeto de manejo de base de datos falso. De esta forma, se asegura de que las pruebas no dependan de una configuración de base de datos concreta, y solo está probando la pequeña porción de código que le interesa, no la capa de manejo de la base de datos completa también.

Al principio puede parecer mucho trabajo, pero este tipo de refactorización es exactamente lo que su marco de prueba debe realizar. Es posible que le resulte útil obtener un libro sobre pruebas de software como referencia para desacoplar sus dependencias. Pagará mucho más que intentar arrancar JUnit desde dentro de la aplicación en ejecución.

Cuestiones relacionadas