Creando pruebas nunit sin exportarlas con la api.

Question

Soy nuevo en las pruebas unitarias usando nunit (y desarrollo de Java en general). Al crear pruebas unitarias para métodos privados en clases, parece que el archivo de prueba debe estar en el mismo paquete que la clase que se está probando. ¿Cuál es la forma típica de evitar exportar las API de las pruebas unitarias? ¿Puedo hacer que las clases / métodos de prueba estén protegidos contra paquetes? ¿O los desarrolladores suelen tener una versión de compilación separada que excluye los archivos de prueba de unidad?

Answer 1

El archivo de prueba no necesariamente tiene que estar en el mismo paquete que la clase que se está probando. De hecho, es una buena práctica tener los archivos de prueba en un paquete completamente separado, lo que les permite probar la API pública sin preocuparse por los detalles de la implementación a nivel de paquete.

Alternativamente, puede configurar su secuencia de comandos de compilación (por ejemplo, Nant) para ignorar los archivos que contienen " Prueba " cuando construyes tu versión ejecutable.

Answer 2

Puedo decirle a IntelliJ o Ant que no empaqueten las pruebas de JUnit en la implementación. Tengo pruebas en un directorio separado del código fuente, que es lo que lo hace posible.

No mezcle fuentes de fuente y prueba juntas. Manténgalos separados para que sea más fácil para la herramienta / script que usa para implementar.

Answer 3

Personalmente, mi enfoque es solo probar la funcionalidad expuesta, por lo que termina probando solo partes bien encapsuladas.

Esto generalmente hace que mi diseño contenga clases pequeñas con una funcionalidad bien definida, que son más fáciles de probar.

En general, cuando realiza pruebas de unidad, no debe preocuparse por los aspectos internos de lo que está probando, por lo que creo que esta es la mejor manera de abordarlo.

También estoy de acuerdo en que es mejor separar el código de producción y prueba.

Answer 4

Mantenga el código fuente de prueba fuera del código fuente de la aplicación. En general, solo prueba la funcionalidad expuesta. Si realmente necesita probar el comportamiento privado, cree un objeto de prueba que extienda el objeto real y le permita al público acceder al comportamiento privado.

Answer 5

Creo que es un error sacar su código de prueba del paquete de la CUT (Clase en prueba). En algún momento, es posible que desee probar un método o clase protegidos, y tener su código de prueba en otro paquete lo hace difícil o imposible.

Una mejor solución es crear un directorio separado para su código de prueba que simplemente refleje la estructura del paquete de su código de producción. Esto es lo que hago:

src/main/java/com/example/Foo.java
src/test/java/com/example/FooTest.java

Luego, su script de compilación puede ignorar muy simplemente src / test / ** cuando llegue el momento del empaquetado y la implementación.