java - tutorial - ¿Dónde debo poner mis pruebas de JUnit?
test junit netbeans (4)
Tengo 2 preguntas sobre la organización de pruebas unitarias.
¿Tengo que poner la prueba en el mismo paquete que la clase examinada, o puedo organizar pruebas en diferentes paquetes?
Por ejemplo, si tengo validez y otras pruebas, ¿es correcto dividirlas en paquetes diferentes, incluso si son para la misma clase?
¿Qué pasa con las clases de simulacro y talón? ¿Debo separarlos de los paquetes que contienen solo pruebas o juntarlos?
La forma en que hacemos nuestros casos de prueba JUnit es colocarlos en el mismo paquete, pero en un directorio raíz diferente. Como usamos Maven, solo usamos las ubicaciones estándar para 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 com.foo.test separado que reside solo en el árbol src/test/java .
Las clases de prueba deben estar más bien en paquetes diferentes, es más fácil separarlos del código de producción cuando lo empaqueta 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.
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, y solo una, clase de prueba 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 ninguna clase de prueba, y eso está bien, pero cuando se quiere saber qué prueba evalúa una determinada clase, tener una convención que diga que ClassNameTest es la prueba para ClassName es muy útil
Sin embargo, TestNG es mucho más amigable con este paradigma que JUnit.
Yo también tiendo a poner mis pruebas en el mismo paquete pero bajo 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 mantienen en un árbol de directorio separado para permitir que se excluyan del resultado desplegado (en particular para garantizar que el código de prueba no se haya introducido accidentalmente en el código de producción). Lo que más importa, sin embargo, 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 se escribe una clase de prueba por aparato, es decir, por estructura de configuración. En muchos casos, es lo mismo (o lo suficientemente cerca) de 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).
Sobre todo, no me preocupo demasiado por la teoría, sino que repito las pruebas según sea necesario para mantener la duplicación al mínimo absoluto.