Go synctest: Решение проблемы нестабильных тестов

[comerc]

// .vscode/settings.json

{
  "go.testEnvVars": {
    "GOEXPERIMENT": "synctest"
  },
  "go.testFlags": [
    "-v"
  ],
  "go.buildTags": "goexperiment.synctest"
}

// .vscode/launch.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug Synctest",
      "type": "go",
      "request": "launch",
      "mode": "test",
      "program": "${workspaceFolder}",
      "env": {
        "GOEXPERIMENT": "synctest"
      },
      "args": [
        "-test.run",
        ".*Synctest.*",
        "-test.v"
      ],
      "buildFlags": "-tags=goexperiment.synctest"
    },
    {
      "name": "Debug Current Synctest",
      "type": "go",
      "request": "launch",
      "mode": "test",
      "program": "${fileDirname}",
      "env": {
        "GOEXPERIMENT": "synctest"
      },
      "buildFlags": "-tags=goexperiment.synctest"
    }
  ]
}

// Makefile

check:
	GOEXPERIMENT=synctest go test -short -failfast -v -race -count=1 ./...

[aamonster]

Кажется, автор не понимает идею тестов.

После устранения нестабильности тест TestSharedValue должен не всегда проходить успешно, а всегда фэйлиться. Просто потому, что в реальной жизни он может так сделать, и надо это обнаружить заранее.

[cmyser]

этот тест логику не проверяет, если бы там синкались горутины из бизнес логики, тогда да, воппросики были бы)
но опять же для suit cценариев полезно, а так же для старта приложений что бы не писать обработчики ожидания того что база или сервер стартанул

[aamonster]

что бы не писать обработчики ожидания того что база или сервер стартанул

Надо писать. Тем более в многопоточном/многопроцессном приложении это вообще халява, никаких тебе колбэков или async-await, просто поставить в код вызов типа "WaitForServiceStarted()".

[cmyser]

Ну не сказал бы, в каждом проекте одно и тоже

А так хочется фреймворк)