Тестирование двунаправленного RPC на Голанге - PullRequest
Новая
       22

Тестирование двунаправленного RPC на Голанге

0 голосов
/ 15 февраля 2019

Я следовал некоторым руководствам по созданию двунаправленного клиента и сервера grpc.Клиент передаст некоторое значение, и когда последнее максимальное значение будет изменено на сервере, он ответит клиенту с текущим макс.Наконец, я хотел бы записать некоторые тестовые случаи, но у меня нет опыта в тестировании сценариев, поэтому я не уверен, правильно ли я поступаю или нет. 

func TestClientConnection(t *testing.T) {

    creds, _ := credentials.NewClientTLSFromFile("../server-cert.pem", "")
    conn, err := grpc.Dial(address, grpc.WithTransportCredentials(creds))
    if err != nil {
        t.Error("Had problem with connection, NOT PASSED")
    }
    defer conn.Close()

    c := proto.NewHerdiusServerClient(conn)

    stream, err := c.CheckMax(context.Background())
    if err != nil {
        t.Error("Had problem with stream, NOT PASSED")
        return
    }

    err = stream.Send(&proto.MaxRequest{Val: int32(10)})
    err = stream.Send(&proto.MaxRequest{Val: int32(12)})
    err = stream.Send(&proto.MaxRequest{Val: int32(13)})
    err = stream.Send(&proto.MaxRequest{Val: int32(9)})

    if err != nil {
        t.Error("Had problem with stream, NOT PASSED")
        return
    }

    return
}

Прямо сейчаскогда я тестирую этот сценарий с go test, он проходит, но я также хочу проверить, получено ли что-то со стороны сервера.

Мой второй вопрос был: «Хочу ли я разорвать этот тест для других сценариев, например, чтобы проверить сервер»подключен или подключен поток или получен ответ со стороны сервера, как я могу это сделать?Должен ли я создать другой класс для извлечения соединения, потоковой передачи и использования в тестовых функциях?

1 Ответ

0 голосов
/ 15 февраля 2019

Создайте конкурс с тайм-аутом context.WithTimeout, и после отправки ваших данных вызовите Recv в потоке.Проверьте, получаете ли вы что-либо в течение тайм-аута.

Особенности зависят от протокола здесь - вам может потребоваться программа на Recv, если вам необходимо одновременно отправлять данные с сервера.

Что касается вашего второго вопроса, философия Go состоит в том, чтобы иметь четкие, четкие, читаемые тесты для каждого сценария.Это нормально, если какой-то код дублируется.Гораздо важнее, чтобы каждый отдельный тест был читабельным и понятным.В случаях, когда тесты очень повторяются, следует использовать тесты, управляемые таблицами , но в описанных вами случаях это звучит для меня как отдельные тесты.

Полезно иметь тесты, которые "накапливаются"функциональность.Один тест для проверки соединения, другой - соединение и отправка, еще одно соединение - отправка и получение.Таким образом, когда тесты не выполняются, перезапуская их по отдельности, вы можете очень быстро изолировать проблему даже до того, как посмотрите на код теста.

...