java - tutorial - Separación de las clases JUnit en un paquete de prueba especial?
junit netbeans (3)
Estoy aprendiendo los conceptos del desarrollo basado en pruebas mediante la lectura de los artículos de Craftsman (haga clic en Craftsman en Por tema ) recomendados en una respuesta a mi pregunta anterior, "Proyecto de ejemplo para aprender JUnit y la ingeniería de software adecuada" . ¡Me encanta hasta ahora!
Pero ahora quiero sentarme y probarlo yo mismo. Tengo una pregunta que espero necesite solo una respuesta simple.
¿Cómo organizas tus clases de prueba JUnit y tu código real? Estoy hablando principalmente de la estructura del paquete, pero cualquier otro concepto de nota sería útil también.
¿Pone clases de prueba en org.myname.project.test. * Y código normal en org.myname.project. *? ¿Pone las clases de prueba junto a las clases normales? ¿Prefieres prefijar los nombres de clase con Prueba en lugar de sufijarlos?
Sé que parece algo de lo que no debería preocuparme tan pronto, pero soy una persona muy centrada en la organización. Soy casi el tipo de persona que dedica más tiempo a encontrar métodos para hacer un seguimiento de qué hacer, en lugar de hacer las cosas.
Y tengo un proyecto que actualmente está dividido en paquetes, pero el proyecto se convirtió en un desastre. En lugar de tratar de refactorizar todo y escribir pruebas, quiero comenzar de nuevo, probar primero y todo. Pero primero necesito saber a dónde van mis exámenes.
editar: ¡ Me olvidé por completo de Maven, pero parece que la mayoría de ustedes lo está usando! En el pasado, tenía un caso de uso específico en el que Maven se derrumbaba por completo sobre mí, pero Ant me daba la flexibilidad que necesitaba, así que terminé vinculado a Ant, pero estoy pensando que tal vez estaba tomando el enfoque equivocado. Creo que volveré a intentar con Maven porque parece que funcionará bien con el desarrollo basado en pruebas.
Prefiero poner las clases de prueba en el mismo paquete que las clases de proyecto que prueban, pero en un directorio físico diferente, como:
myproject/src/com/foo/Bar.java
myproject/test/com/foo/BarTest.java
En un proyecto de Maven, se vería así:
myproject/src/main/java/com/foo/Bar.java
myproject/src/test/java/com/foo/BarTest.java
El punto principal en esto es que mis clases de prueba pueden acceder (y probar) clases y miembros del alcance del paquete.
Como muestra el ejemplo anterior, mis clases de prueba tienen el nombre de la clase probada más Test como sufijo. Esto ayuda a encontrarlos rápidamente; no es muy divertido intentar buscar entre un par de cientos de clases de prueba, cada uno de cuyos nombres comienza con Test ...
Actualización inspirada en el comentario de @ Ricket: de esta manera, las clases de prueba (normalmente) aparecen justo después de que su compañero probado aparezca en una lista alfabética de los nombres de clase. (Es curioso que me esté beneficiando de este día a día, sin haberme dado cuenta conscientemente de cómo ...)
Actualización 2: Muchos desarrolladores (incluido yo) como Maven, pero parece que hay al menos tantos que no. En mi humilde opinión, es muy útil para los proyectos "mainstream" de Java (pondría alrededor del 90% de los proyectos en esta categoría ... pero el otro 10% sigue siendo una minoría considerable). Es fácil de usar si uno puede aceptar las convenciones de Maven; sin embargo, si no, hace que la vida sea una lucha miserable. Maven parece ser difícil de comprender para muchas personas socializadas en Ant, ya que aparentemente requiere una forma muy diferente de pensar. (Yo, que nunca he usado Ant, no puedo comparar los dos.) Una cosa es segura: hace que las pruebas unitarias (y de integración) sean un paso natural de primera clase en el proceso, lo que ayuda a los desarrolladores a adoptar esta práctica esencial.
Puse mis clases de prueba en el mismo paquete que lo que están probando, pero en una carpeta de origen o proyecto diferente . Organizar mi código de prueba de esta manera me permite compilarlo y empaquetarlo fácilmente por separado para que los archivos jar de producción no contengan código de prueba. También permite que el código de prueba acceda a campos y métodos privados del paquete.
Yo uso Maven . La estructura que promueve Maven es:
src/main/java/org/myname/project/MyClass.java
src/test/java/org/myname/project/TestMyClass.java
es decir, una clase de prueba con Prueba antepuesta al nombre de la clase bajo prueba está en una estructura de directorio paralelo a la prueba principal.
Una ventaja de tener las clases de prueba en el mismo paquete (aunque no necesariamente el directorio) es que puede aprovechar los métodos de alcance de paquete para inspeccionar o inyectar objetos de prueba falsos.