Pruebas de Golang en el subdirectorio
Quiero crear un paquete en Go con pruebas y ejemplos para el paquete como subdirectorios para mantener más limpio el espacio de trabajo. ¿Es posible? y si lo es, ¿cómo?
Toda la documentación siempre coloca el código de prueba en el mismo lugar que el otro código. ¿Es esto mejor de alguna manera o simplemente una convención?
Tenga en cuenta que puede ejecutar go test"recursivamente": debe enumerar todos los paquetes que desea probar .
Si estás en la carpeta raíz de tu proyecto Go, escribe:
go test ./...
La ./...notación ' ' se describe en la sección " Descripción de listas de paquetes " del " comandogo ":
Una ruta de importación es un patrón si incluye uno o más
...comodines " ", cada uno de los cuales puede coincidir con cualquier cadena, incluidas la cadena vacía y las cadenas que contienen barras.Dicho patrón se expande a todos los directorios de paquetes que se encuentran en los
GOPATHárboles con nombres que coinciden con los patrones.Como caso especial,
x/...coincidenciasxyxsubdirectorios.
Por ejemplo,net/...se expandenety empaqueta en sus subdirectorios.
Si guarda sus _test.goarchivos en una subcarpeta, el go test ./...comando '' podrá recuperarlos.
Pero:
- deberá anteponer las variables y funciones exportadas (utilizadas en sus pruebas) con el nombre de su paquete, para que el archivo de prueba pueda acceder al contenido exportado del paquete.
- no accederías a contenido no exportado.
Dicho esto, seguiría prefiriendo mantener el _test.goarchivo justo al lado del archivo fuente principal: es más fácil de encontrar.
2022: Para cobertura de código:
go test -coverpkg=./... ./...
Consulte " Cómo trazar la cobertura de la prueba de Go a lo largo del tiempo " de Frédéric G. MARAND y fgmarand/gocoverstatspara producir estadísticas de cobertura agregadas para la integración de CI de proyectos de Go.
Además, go-cover-treemap.ioes divertido.
Marzo de 2023: como se documenta en " Cobertura de código para pruebas de integración de Go ":
Con la versión 1.20, las herramientas de cobertura de Go ya no se limitan a pruebas de paquetes, sino que admiten la recopilación de perfiles de pruebas de integración más grandes.
Ejemplo:
$ go build -cover -o myprogram.exe myprogram.go
$ mkdir somedata
$ GOCOVERDIR=somedata ./myprogram.exe
I say "Hello, world." and "see ya"
$ ls somedata
covcounters.c6de772f99010ef5925877a7b05db4cc.2424989.1670252383678349347
covmeta.c6de772f99010ef5925877a7b05db4cc
Consulte la portada de Go 1.20 .
Como señaló kbolino en los comentarios :
Puede colocar sus pruebas en un paquete separado sin colocarlas en un directorio separado.
Los archivos de prueba para el paquete foo pueden estar en el paquetefoo_testy aún estar en el mismo directorio, sin tener acceso a miembros no exportados (privados) del paquetefoo.
EDITADO
Basado en la respuesta de VonC,
Esta respuesta es válida en go1.11. Aún no probado en goversiones superiores.
Para aquellos de ustedes a quienes les gusta mantener sus pruebas en una subcarpeta, digamos testy luego ejecutan
go test ./...
intentará ejecutar pruebas en todas las carpetas, incluso aquellas que no contienen ninguna prueba, por lo que tendrá un ?informe posterior para las carpetas que no son de prueba.
Correr
go test ./.../test
en su lugar, se dirigirá solo a sus testcarpetas, por lo que tendrá un informe limpio centrado únicamente en sus carpetas de pruebas.
PRECAUCIÓN
Tenga en cuenta que el uso de subcarpetas de prueba impedirá el cálculo del informe de cobertura. La filosofía de go es dejar archivos de prueba en las carpetas del paquete.
Coloque sus pruebas junto con su código en el mismo directorio en un archivo llamado file_test.godonde "archivo" es el nombre del archivo de código fuente que está probando. Esto es una convención y, según mi propia experiencia, he descubierto que es lo mejor.
Si la go testherramienta no está lo suficientemente automatizada para usted, puede consultar GoConvey , que tiene una interfaz de usuario web que actualizará y ejecutará automáticamente las pruebas de Go tradicionales, así como las pruebas de GoConvey (que se basan en el comportamiento y se autodocumentan más). que las pruebas Go tradicionales).
