Как unit test облачное хранилище Google в golang?

Я пишу приложение на Go, которое использует облачное хранилище Google.

Например, мой "читающий" код выглядит так:

client, err := storage.NewClient(ctx)
if err != nil {
    return nil, err
}
defer func() {
    if err := client.Close(); err != nil {
        panic(err)
    }
}()
r, err := client.Bucket(BucketName).Object(id).NewReader(ctx)
if err != nil {
    return nil, err
}
defer r.Close()
return ioutil.ReadAll(r)

... где ctx - это контекст из appengine.

Когда я запускаю этот код в модульном тесте (используя aetest), он фактически отправляет запросы в мое облачное хранилище; Вместо этого я хотел бы выполнить это герметично, подобно тому, как aetest разрешает ложные вызовы хранилища данных.

(Возможно связанный вопрос, но он имеет дело с python, и связанная проблема github указывает, что он решен специфичным для python способом).

Как я могу это сделать?

Ответ 1

Один из подходов, также предлагаемый здесь, должен позволить вашему клиенту GCS, чтобы его загрузчик был заменен на заглушку во время модульного тестирования. Сначала определите интерфейс, который соответствует тому, как вы используете библиотеку Google Cloud Storage, а затем переопределите его поддельными данными в своих модульных тестах.

Что-то вроде этого:

type StorageClient interface {
  Bucket(string) Bucket  // ... and so on, matching the Google library
}

type Storage struct {
  client StorageClient
}

// New creates a new Storage client
// This is the function you use in your app
func New() Storage {
  return Storage{
    client: realGoogleClient,
  }
}

// NewWithClient creates a new Storage client with a custom implementation
// This is the function you use in your unit tests
func NewWithClient(client StorageClient) {
  return Storage{
    client: client,
  }
}

Это может быть много шаблонов, чтобы издеваться над всеми сторонними API-интерфейсами, поэтому, возможно, вы сможете сделать это проще, создав некоторые из этих mocks с помощью golang/mock или mockery.

Ответ 2

Облачное хранилище на сервере разработки Python эмулируется с использованием локальных файлов с помощью службы Blobstore, поэтому работа с использованием шаблона Blobstore с тестовым стендом (также с использованием Python). Тем не менее, такая локальная эмуляция для Cloud Storage в режиме run отсутствует.

Как предположил Сачин, путь к unit test Cloud Storage - использовать макет. Это делается так, как это делается внутри и на других этапах выполнения, например node.

Ответ 3

Я бы посоветовал вам уменьшить количество ложных изданий настолько, насколько это возможно, вам может понадобиться герметичный подход, чтобы сделать его почти похожим на настоящий. https://testing.googleblog.com/2012/10/hermetic-servers.html