tools - type of web testing

Organizar pruebas en aplicación golang y evitar ciclos de importación infernales

Question

Actualmente estoy experimentando un problema de arquitectura de la estructura de la aplicación y su infraestructura de prueba.

Aquí hay una breve descripción del diseño

<GOROOT>/src/myapp/controllers/
<GOROOT>/src/myapp/controllers/account.go
...
<GOROOT>/src/myapp/models/
<GOROOT>/src/myapp/models/account.go
<GOROOT>/src/myapp/models/account_test.go
...
<GOROOT>/src/myapp/components/
<GOROOT>/src/myapp/components/comp1/
<GOROOT>/src/myapp/components/comp1/impl.go
<GOROOT>/src/myapp/components/comp1/impl_test.go
<GOROOT>/src/myapp/components/
...
<GOROOT>/src/myapp/testutil/
<GOROOT>/src/myapp/testutil/database.go
<GOROOT>/src/myapp/testutil/models.go
...

Problema 1

File myapp/testutil/models.go contiene algunas funciones de myapp/testutil/models.go utilizadas en las pruebas de models/*_test.go Las funciones de utilidad realmente usan el paquete de myapp/models de estructuras de datos y funciones. Por lo tanto, tenemos un ciclo de importación: el paquete account_test.go imports testutil , que a su vez importa models .

La única solución clara aquí es mantener testutil/models.go dentro de los paquetes de los models en el mismo paquete, algo así como test_utils.go , que me parece un poco torpe. ¿Cuál sería el mejor recorrido en estos casos?

Problema 2

testutil paquete testutil tiene alguna inicialización del comp1 (digamos que es un cliente para un servicio de terceros). Cuando ejecutamos una prueba comp1/impl_test.go el paquete testutil se importa, e importa el paquete comp1 ya que es responsable de la inicialización del componente. El mismo infierno cíclico de importación. Mover la inicialización a cada lugar individual en los casos de prueba parece una duplicación de código. Todavía estoy buscando algunas soluciones elegantes aquí ...

Answer 1

Problema 1

Si el package testutils solo proporciona las funciones de utilidad utilizadas durante las pruebas del package module del package module simplemente ponga esas funciones en los models/testutils_test.go : Ahora, esta función de utilidad se incluirá al ejecutar las pruebas de models/*_test.go No hay ciclo de importación por más tiempo.

Esta es su "única solución clara" y no puedo ver nada "torpe" con ella.

Problema 2

Ciclo de importación: igual que el anterior.

Inicialización: su comp1/impl_test.go puede proporcionar un func init() para que no haya necesidad de código duplicado.

(La biblioteca estándar es una buena fuente de cómo probar cosas diferentes. La duplicación del código IMHO en el código de prueba no es uno de los siete pecados capitales).