Tenemos la mejor información que descubrimos online. Queremos que te sirva de ayuda y si quieres comentarnos algo que nos pueda ayudar a crecer hazlo libremente.
Solución:
Puede quitar el código generado de los perfiles de portada:
go test . -coverprofile cover.out.tmp
cat cover.out.tmp | grep -v "_generated.go" > cover.out
tool cover -func cover.out
Dependiendo de las herramientas utilizadas, esto se puede implementar fácilmente en el pipeline/make.
La mayoría de las herramientas de Go funcionan con paquetes, porque un paquete en sí forma un unidad que puede ser útil en su totalidad. La exclusión de archivos de un paquete podría “romper” fácilmente el paquete: el archivo excluido puede contener un código de inicialización del paquete (crucial) o incluso puede hacer que los archivos restantes del paquete no se compilen.
go test no es una excepción: también opera sobre paquetes. No hay soporte de primera mano para excluir archivos de un paquete.
Si su paquete se puede compilar y probar sin el archivo generado, puede optar por generar el archivo en un paquete diferente, y luego no se incluirá en la prueba (cobertura) de su paquete de forma natural.
Otra forma de manejar esto sería generarlo en el mismo paquete/carpeta y usar etiquetas de compilación especiales en los archivos generados, que puede excluir al ejecutar la prueba de cobertura. Puede leer más sobre las etiquetas de compilación aquí: Restricciones de compilación y aquí: ¿Cuál es el enfoque correcto para encapsular el código específico de la plataforma en Go?
Si el archivo generado es necesario para compilar/probar el paquete, aún tiene una opción: usar un interno paquete para el archivo generado. Los paquetes internos solo están disponibles para el árbol de paquetes enraizado en el internal carpeta, lo que significa que puede exportar cualquier identificador en un paquete interno, el compilador garantiza que no serán utilizados por partes “no deseadas”. Puede leer más sobre los paquetes internos aquí: ¿Puedo desarrollar un paquete go en múltiples directorios fuente?
Considere también la opción de escribir o generar una prueba para el código generado, que puede ser una buena práctica de todos modos, por lo que no tendría que usar trucos para excluirlos de las pruebas de cobertura.
Siguiendo las vías que pude solucionar esta necesidad.
Excluyendo dirs/pkgs
Dado que para ejecutar la prueba y generar la portada, especificará los paquetes donde el comando go test debe buscar, los archivos fuera de este paquete se ignorarán automáticamente. Siguiendo un ejemplo
project
|_______/pkg/web/app
|_______/pkg/web/mock -> It will be ignored.
# Command:
$go test -failfast -tags=integration -coverprofile=coverage.out -covermode=count github.com/aerogear/mobile-security-service/pkg/web/apps
Sin embargo, no se puede aplicar en todos los casos. Por ejemplo, en el caso de que los archivos sean rutinas simuladas de sus interfaces, es posible que no funcione muy bien porque las importaciones que se requieren en el servicio, la prueba y el simulacro probablemente estarán en un ciclo y en esto no están permitidas.
Usando “_test” en las definiciones de nombres
Si desea ignorar los archivos que se utilizan en las pruebas, tiene sentido utilizar _test al final del nombre. Por ejemplo, my_service_mock_test.go. Los archivos con _test al final del nombre será ignorado por defecto.
Al eliminar del archivo de portada de la siguiente manera
go test . -coverprofile cover.out.tmp
cat cover.out.tmp | grep -v "_generated.go" > cover.out
tool cover -func cover.out
PD.: No pude encontrar un comentario o etiqueta que los excluyera.
Tienes la opción de añadir valor a nuestra información contribuyendo tu experiencia en las explicaciones.