test mock golang create testing go

testing - create - mock golang



EjecuciĆ³n en serie de pruebas de paquetes. (3)

Como han señalado otros, -paralelo no hace el trabajo (solo funciona dentro de paquetes). Sin embargo, puede usar el indicador -p = 1 para ejecutar las pruebas de paquetes en serie. Esto se documenta aquí:

http://golang.org/src/cmd/go/testflag.go

pero (afaict) no está en la línea de comando, vaya a ayudar, etc. No estoy seguro de que esté destinado a quedarse (aunque diría que si se elimina, debe solucionarse el paralelo).

He implementado varios paquetes para una API web, cada uno con sus propios casos de prueba. Cuando cada paquete se prueba utilizando go test ./api/pkgname las pruebas pasan. Si quiero ejecutar todas las pruebas a la vez con go test ./api/... los casos de prueba siempre fallan.

En cada caso de prueba, recreo todo el esquema usando DROP SCHEMA public CASCADE seguido de CREATE SCHEMA public y aplico todas las migraciones. El conjunto de pruebas informa los errores al azar, diciendo que no existe una relación / tabla, por lo que supongo que cada conjunto de pruebas (por paquete) se ejecuta en paralelo de alguna manera, lo que confunde el estado del DB.

Intenté pasar algunas banderas de prueba como go test -cpu 1 -parallel 0 ./src/api/... sin éxito.

¿Podría el problema aquí ser pruebas ejecutándose en paralelo, y si es así, cómo puedo forzar la ejecución en serie?

Actualizar:

Actualmente utilizo esta solución para ejecutar las pruebas, pero todavía me pregunto si hay una solución mejor.

find <dir> -type d -exec go test {} /;


La herramienta ir se proporciona para facilitar la ejecución de las pruebas unitarias utilizando la convención de que los archivos * _test.go contienen pruebas de unidad en ellas. Como asume que son pruebas de unidad, también asume que son herméticos. Parece que sus pruebas no son pruebas de unidad o lo son, pero violan las suposiciones que debe cumplir una prueba de unidad.

En el caso de que te refieras a que estas pruebas sean pruebas de unidad, entonces probablemente necesites una base de datos simulada para tus pruebas de unidad. Un simulacro, preferiblemente en memoria, de su base de datos garantizará que la prueba de unidad sea hermética y no pueda ser interferida por otras pruebas de unidad.

En el caso de que quiera que estas pruebas sean pruebas de integración, probablemente sea mejor que no use la herramienta go para estas pruebas. Lo que probablemente desee es crear un binario de prueba separado cuya ejecución pueda controlar y escribir sus scripts de prueba de integración allí.

La buena noticia es que crear un simulacro en Go es increíblemente fácil. Cambie su código para tener una interfaz con los métodos que le interesan en las bases de datos y luego escriba una implementación en memoria de esa interfaz para fines de prueba y pásela al código de la aplicación que desea probar.


Solo para aclarar, la respuesta de @ Jeremy sigue siendo la aceptada:

Dado que mis pruebas de integración solo se ejecutaron en un paquete ( api ), eliminé el binario de prueba separado al final y creé un patrón para separar los tipos de prueba al:

  • Las pruebas unitarias usan el nombre normal de TestX
  • Pruebas de integración utilizan Test_X

utest.sh shell scripts ( utest.sh / itest.sh ) para ejecutar cualquiera de esos.

  • Para pruebas unitarias, go test -run="^(Test|Benchmark)[^_](.*)"
  • Para las pruebas de integración, go test -run"^(Test|Benchmark)_(.*)"
  • Ejecutar ambos usando la go test normal