¿Dónde debo poner mis pruebas JUnit?

Question

Tengo 2 preguntas sobre la organización de pruebas de unidad.

1. ¿Tengo que poner la prueba en el mismo paquete que la clase probada, o puedo organizar las pruebas en diferentes paquetes?

   Por ejemplo, si tengo validez y otras , ¿es correcto dividirlas en diferentes paquetes, incluso si son para la misma clase?

2. ¿Qué pasa con las clases de simulacros y de código auxiliar? ¿Debo separarlos de los paquetes que contienen solo pruebas o juntarlos?

Answer 1

La forma en que hacemos nuestros casos de prueba JUnit es ponerlos en el mismo paquete, pero en un directorio raíz diferente. Como usamos Maven, solo usamos las ubicaciones estándar que hacen que la estructura sea similar a la siguiente.

src/main/java/com/foo/Bar.java
src/test/java/com/foo/BarTest.java

Obviamente hay más en la estructura, pero esto nos permite construir las pruebas por separado del código de la línea principal, pero aún así acceder a clases protegidas y similares. Con respecto a los diferentes tipos de pruebas, esto es muy subjetivo. Cuando comenzamos nuestro esfuerzo de prueba (que desafortunadamente comenzó después del desarrollo), traté de mantener las cosas bastante aisladas. Desafortunadamente, rápidamente se convirtió en una pesadilla cuando llegamos al punto de prueba de más de 500. Desde entonces he tratado de hacer más consolidación. Esto llevó a cantidades reducidas de código para mantener. Como dije, sin embargo, es muy subjetivo.

En cuanto al código de solo prueba, lo guardamos en un paquete separado de com.foo.test que reside solo en el árbol src / test / java .

Answer 2

Yo también tiendo a poner mis pruebas en el mismo paquete pero en un directorio raíz diferente. Esto me permite probar clases privadas de paquetes o acceder a clases privadas de paquetes mientras pruebo otra cosa en el paquete. Se guardan en un árbol de directorios separado para permitir excluirlos del resultado implementado (en particular para garantizar que el código de prueba no ingrese accidentalmente en el código de producción). Sin embargo, lo que más importa es lo que funciona para su situación.

En términos de cuántas clases de prueba por clase de producción, la teoría que he visto es que usted escribe una clase de prueba por dispositivo, es decir, por estructura de configuración. En muchos casos, eso es lo mismo (o lo suficientemente cercano) a una clase de prueba por clase de producción, pero a veces he escrito más clases de prueba (en particular, las pruebas de igualdad tienden a estar separadas) para una clase de producción dada, y ocasionalmente una clase de prueba de para un grupo de clases de producción (relacionadas) (por ejemplo, para probar el patrón de la Estrategia).

Principalmente, no me preocupo demasiado por la teoría, pero reviso las pruebas según sea necesario para mantener la duplicación al mínimo absoluto.

Answer 3

Las clases de prueba deberían estar en diferentes paquetes, es más fácil separarlas del código de producción cuando lo empacas para su lanzamiento. Por lo general, mantengo un montón de pelusa de prueba en esos paquetes, todo tipo de simulacros, configuraciones, escenarios ... Pero cuando construyes, no lo consigues. En algunas situaciones, es una buena idea mantener tus pruebas en diferentes proyectos. Depende.

Answer 4

Mantenerlo en el mismo paquete le permite utilizar la visibilidad privada del paquete para el código que se pretende acceder solo a través de la prueba.

Con respecto al uso de directorios raíz separados, es una buena práctica. También tiene una ventaja para nosotros, ya que usamos IDEA, IDEA reconoce que el código de producción no puede hacer referencia al código de prueba.

En términos de mantenerlos separados, hay un gran poder para tener una clase de prueba, y solo una, por clase de producción a nivel de unidad. Por supuesto, algunas clases se crean en producción como parte de la refactorización que no tienen clases de prueba, y eso está bien, pero cuando quieres saber qué prueba prueba una clase determinada, tener una convención que dice ClassNameTest es la prueba para ClassName es muy útil.

Sin embargo, TestNG es mucho más amigable con este paradigma que JUnit.