Pruebas unitarias Java, diseño de directorio

Question

Al crear un conjunto de pruebas unitarias para el código Java, ¿existe una convención para dónde colocar el código de prueba en relación con el código fuente?

Por ejemplo, si tengo un directorio /java que contiene un montón de .java archivos de origen, ¿es mejor poner los casos de prueba en /java sí mismo o usar algo como /java/test.

Si se prefiere este último, ¿cómo se prueba la parte interna del código cuando los miembros private/protected de una clase no están disponibles fuera del paquete?

Answer 1

Usted puede poner las pruebas en el mismo paquete que las clases originales, incluso si el código fuente se encuentra bajo su propio directorio raíz:

PROJECT_ROOT 
    +--- src/ 
    +----test/ 

Se puede declarar una clase com.foo.MyClass bajo src y su prueba de com.foo.MyClassTest bajo test.

En cuanto al acceso a los miembros privados, puede utilizar reflexión para invocar los métodos (alterando su accesibilidad a través de Class.getDeclaredMethod.setAccessible), o usted podría utilizar algo como TestNG/junit5 poner algunas pruebas de anotación impulsada en el propio código fuente (Personalmente creo que esta es una mala idea).

¿Por qué no ver algunos proyectos en java.net para ver cómo han organizado cosas, por ejemplo swinglabs (me temo que el repositorio SVN es bastante lento)?

Answer 2

mayoría de las veces se hace así:

<SOME_DIR>/project/src/com/foo/Application.java 
<SOME_DIR>/project/test/com/foo/ApplicationTest.java 

Por lo tanto, mantenerlos separados y todavía se puede probar la funcionalidad del paquete/protegida porque la prueba está en el mismo paquete.

No puede probar cosas privadas, a menos que se declare dentro de la clase.

momento de la entrega, que acaba de empacar el .class generados por src, no las pruebas

Answer 3

Recomiendo seguir el Apache Software Foundation's standard directory structure, que produce esto:

module/ 
    src/ 
    main/ 
     java/ 
    test/ 
     java/ 

Esto mantiene a pruebas por separado de la fuente, pero al mismo nivel en la estructura del directorio. Si lee cómo Apache define su estructura, verá que también ayuda a separar otras preocupaciones, incluidos recursos, archivos de configuración, otros idiomas, etc.

Esta estructura también permite pruebas unitarias para probar paquetes y niveles protegidos métodos de las unidades bajo prueba, suponiendo que coloque sus casos de prueba en el mismo paquete que lo que prueban. En cuanto a probar métodos privados, no me molestaría. Otra cosa, ya sea pública, de paquete o protegida, los llama y usted debe poder obtener pruebas de cobertura de prueba completa de esas cosas.

Por cierto, el enlace de arriba es para Maven, la herramienta de construcción estándar de Apache. Todos los proyectos de Java que cumplen se ajustan a este estándar, así como también a todos los proyectos que he encontrado que están construidos con Maven.

Answer 4

En realidad, tiene mucho sentido separar sus proyectos de Producción y Prueba en dos entidades separadas, pero tienen la misma estructura de paquete en ambos proyectos.

Así que si tengo un proyecto 'mi-proyecto' Yo también crear 'mi-proyecto-test', por lo que tienen la siguiente estructura de directorios:

my-project 
    +--- src/com/foo 
my-project-test 
    +---test/com/foo 

Este enfoque asegura que las dependencias de código de prueba no lo hacen contaminar el código de producción.

En mi opinión personal, los métodos privados y protegidos del paquete deben probarse, así como los métodos públicos. Por lo tanto, quiero que mis clases de prueba estén en el mismo paquete que las clases de producción.

Answer 5

Así es como lo tenemos configurado y nos gusta.

build/ 
src/ 
test/build/ 
test/src/ 

Todo el código de prueba se compila en su propio directorio de compilación. Esto se debe a que no queremos que la producción contenga clases de prueba por error.

Answer 6

Al crear un módulo biblioteca de Java en Android Studio crea una clase por defecto en:

[module] 
    + src/main/java/[com/foo/bar] 

Si nos fijamos en [module].iml archivo, encontrará ese camino, así como el camino para las pruebas, que se puede utilizar. El siguiente es un resumen:

<module> 
    <component> 
    <content> 
     <sourceFolder url="file://$MODULE_DIR$/src/main/java" isTestSource="false" /> 
     <sourceFolder url="file://$MODULE_DIR$/src/main/resources" type="java-resource" /> 
     <sourceFolder url="file://$MODULE_DIR$/src/test/java" isTestSource="true" /> 
     <sourceFolder url="file://$MODULE_DIR$/src/test/resources" type="java-test-resource" /> 
    </content> 
    </component> 
</module> 

Lo que puede hacer, en particular, es la creación de un directorio de pruebas para tener la siguiente estructura:

[module] 
    + src/main/java/[com/foo/bar] 
    + src/test/java/[com/foo/bar] 

la estructura anterior será reconocido por Android Studio y sus archivos debajo se incluirá en el módulo.

Supongo que esa estructura es un diseño recomendado para el código y las pruebas.