¿Dónde pones tu prueba de unidad?

Question

He encontrado varias convenciones para las pruebas de unidad de mantenimiento en un proyecto y No estoy seguro de qué enfoque sería adecuado para nuestro próximo proyecto de PHP. Estoy tratando de encontrar la mejor convención para fomentar el fácil desarrollo y accesibilidad de las pruebas al revisar el código fuente. Estaría muy interesado en su experiencia/opinión con respecto a cada uno:

1. Una carpeta para el código productiva, otro para las pruebas unitarias: Esto separa pruebas unitarias de los archivos lógicos del proyecto. Esta separación de es una molestia tanto como una ventaja: Alguien que busque en el código fuente del proyecto supondrá, por lo tanto, navegar por la implementación o las pruebas unitarias (o más comúnmente: la implementación solamente) La ventaja de que las pruebas unitarias sean otro punto de vista para sus clases se pierde; esos dos puntos de vista están demasiado separados IMO.
2. métodos de prueba anotados: Cualquier moderno marco de pruebas de unidad Sé que permite a los desarrolladores crear métodos de ensayo dedicados, anotándolos (@test) y incrustarlos en el código del proyecto. El gran inconveniente que veo aquí es que los archivos del proyecto se abarrotan. Incluso si estos métodos se separan utilizando una cabecera de comentario (como pruebas unitarias por debajo de esta línea) sólo se hincha la clase innecesariamente.
3. archivos de ensayo en las mismas carpetas que los archivos de implementación: Nuestra convención de nomenclatura de archivos dicta que los archivos PHP que contienen las clases (una clase por archivo) deben terminar con .class.php. Me imagino que poner las pruebas de la unidad con respecto a un archivo de clase en otra que termine en .test.php haría presentar las pruebas mucho más presentes a otros desarrolladores sin contaminar la clase. A pesar de que hincha las carpetas del proyecto, en lugar de los archivos de implementación , éste es mi favorito hasta ahora, pero tengo mis dudas: me pensaría que otros han llegado con esto ya, y descartado esta opción por alguna razón (es decir, I no he visto un proyecto Java con los archivos Foo.java y FooTest.java dentro de la misma carpeta.) Tal vez sea porque los desarrolladores de Java hacen un mayor uso de entornos de desarrollo que les permitan un acceso más fácil a las pruebas, mientras que en PHP sin grandes editores han emergido (como Eclipse para java ) - muchos desarrolladores lo saben usar vim/emacs o editores similares con poco soporte para el desarrollo de PHP per se.

¿Cuál es su experiencia con alguna de estas ubicaciones de prueba de unidad? ¿Tiene otra convención que no he enumerado aquí? ¿O estoy sobrevalorando la prueba de la unidad de accesibilidad a los revisores?

Answer 1

Siempre voy por el n. ° 1. Si bien es bueno que estén muy juntos. Mis motivos son los siguientes:

• Creo que hay una diferencia entre el código base y los unittest. Necesito una separación real.
• Los usuarios finales rara vez necesitan ver pruebas de unidad.Ellos solo están interesados ​​en la API. Aunque es bueno que los unittest proporcionen una vista separada del código, en la práctica creo que no se usará para entenderlo mejor. (documentación más descriptiva + ejemplos)
• Debido a que los usuarios finales rara vez necesitan tests de unidad, no quiero confundirlos con más archivos y/o métodos.
• Mis estándares de codificación no son ni la mitad de estrictos para los unittest que para la biblioteca principal. Esta es quizás solo mi opinión, pero no me importa tanto codificar estándares en mis pruebas.

Espero que esto ayude.

Answer 2

Estoy a favor de mantener pruebas unitarias en archivos de origen separados en el mismo directorio que el código de producción (n. ° 3).

Las pruebas de unidad no son ciudadanos de segunda clase, su código debe mantenerse y refactorizarse al igual que el código de producción. Si mantiene las pruebas de su unidad en un directorio separado, el próximo desarrollador que cambie su código de producción puede pasar por alto que hay pruebas de la unidad y no puede mantener las pruebas.

En C++, que tienden a tener tres archivos por clase:

MyClass.h 
MyClass.cpp 
t_MyClass.cpp 

Si está utilizando Vim, entonces mi toggle_unit_tests plug-in para alternar entre archivos de prueba de origen y la unidad puede resultar útil.

Answer 3

La mejor práctica actual es separar las pruebas unitarias en su propio directorio, n. ° 1. Todos los sistemas de "convención sobre configuración" lo hacen así, por ejemplo. Maven, Rails, etc.

Creo que sus alternativas son interesantes y válidas, y la herramienta de soporte está ciertamente allí para soportarlas. Pero no es tan popular (hasta donde yo sé). Algunas personas se oponen a tener pruebas intercaladas con el código de producción. Pero tiene sentido para mí que si siempre escribes pruebas unitarias, que se ubiquen correctamente con tu código. Simplemente parece más simple.