2011-12-01 10 views
22

Estoy buscando una convención de nomenclatura óptima para archivos de prueba de Python que faciliten el uso de diferentes marcos de prueba (unittest, note, pyunit, ...) y que también sea amigable con el descubrimiento automático de prueba para estas herramientas.¿Cuál es la convención de nomenclatura óptima para los archivos de prueba en Python?

Solo quiero un conjunto claro de recomendaciones que requiera una configuración mínima para las herramientas.

  • ¿Nombre del directorio de pruebas? test o tests?
  • ¿Dónde poner las pruebas? en el módulo/testdir o module /../ testdir
  • ¿Probar nombres de archivos usando guiones bajos o guiones? test_0.py o test-0.py

Lo sé, lo tienen demasiado tiempo :)

+3

El "-" ha creado problemas en Python porque viola las reglas que mapean los nombres de los archivos a los nombres de los módulos. ** Nunca ** use nada que no sea un identificador de Python válido como parte de un nombre de archivo de Python. –

Respuesta

12

No llamar el directorio test o que entrará en conflicto con la incorporada en el test paquete.

Las convenciones de nomenclatura se definen en PEP 8. Consulte la sección 'Convenciones de nombres'. ¡Los subrayados son mejores que los guiones!

El diseño de su paquete es un poco más flexible. Tiendo a hacer lo siguiente:

package 
|-- package 
| |-- __init__.py 
| `-- <etc> 
|-- tests 
| `-- <etc> 
|-- setup.py 
|-- README 
|-- LICENCE 
`-- <etc> 

Esto mantiene las pruebas separadas del paquete en sí. La instalación del paquete con setup.py puede instalar solo la fuente, lo que mantiene ordenados a los intérpretes de las personas. Las pruebas están ahí para los desarrolladores que las necesitan cuando obtienen el origen del paquete.

Debería consultar The Hitch Hiker's Guide to Packaging para obtener más información sobre los paquetes de Python.

+2

Gracias! Solo una subpregunta: ¿y si tengo varios submódulos, esto significa que tendré que combinar todas las pruebas en el mismo directorio? O solo debería moverlos a subdirectorios como '/ tests/a /'? – bogdan

+1

Honestamente puede ir de cualquier manera en este caso. Django usa el enfoque que he mencionado y creo que muchos al menos los ponen en un solo lugar. Sin embargo, las aplicaciones de Django tienen las pruebas extendidas y estoy seguro de que muchas personas lo hacen de esta manera también.Me inclinaría a tener las pruebas en un solo lugar por todas partes (sea dentro o fuera de la fuente), pero no puedo pensar en un argumento fuerte para darle de cualquier manera :) – adamnfish

+3

El argumento para mantener las pruebas en un directorio separado es completamente dependiente de la estética. Estoy de acuerdo con @adamnfish en colocarlos por separado en una estructura de directorios que refleje el código, de esa manera es más fácil para un humano encontrar pruebas específicas para ejecutar (como lo hago todo el tiempo durante el desarrollo). Pero si eres propenso a cambiar la estructura del proyecto (agregar y eliminar módulos/archivos) es posible que te pierdas la actualización de las pruebas, pero verás fallas, ¡así lo sabrás! –

1

Depende de la herramienta que esté utilizando para ejecutar sus pruebas.

Si está utilizando nosetest, la filosofía utilizada para detectar la prueba es bastante simple:

If it looks like a test, it’s a test.

Si está utilizando py.test, las convenciones son pretty open too.

Sobre la pregunta "¿dónde poner la prueba", personnaly, prefiero guardar las pruebas en un subdirectorio en cada paquete para asegurarse de que no se olvidó de ejecutar/tocar las pruebas cuando a alguien editar el código;)

Cuestiones relacionadas