Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
G
Grpc
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
tci-gateway-module
Grpc
Commits
a3adf944
Commit
a3adf944
authored
9 years ago
by
Masood Malekghassemi
Browse files
Options
Downloads
Patches
Plain Diff
Clarify interop spec
parent
0a601268
No related branches found
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/interop-test-descriptions.md
+93
-38
93 additions, 38 deletions
doc/interop-test-descriptions.md
with
93 additions
and
38 deletions
doc/interop-test-descriptions.md
+
93
−
38
View file @
a3adf944
...
@@ -55,7 +55,7 @@ Server features:
...
@@ -55,7 +55,7 @@ Server features:
Procedure:
Procedure:
1.
Client calls EmptyCall with the default Empty message
1.
Client calls EmptyCall with the default Empty message
A
sserts:
Client a
sserts:
*
call was successful
*
call was successful
*
response is non-null
*
response is non-null
...
@@ -84,7 +84,7 @@ Procedure:
...
@@ -84,7 +84,7 @@ Procedure:
}
}
```
```
A
sserts:
Client a
sserts:
*
call was successful
*
call was successful
*
response payload type is COMPRESSABLE
*
response payload type is COMPRESSABLE
*
response payload body is 314159 bytes in size
*
response payload body is 314159 bytes in size
...
@@ -110,6 +110,7 @@ Procedure:
...
@@ -110,6 +110,7 @@ Procedure:
}
}
}
}
```
```
3.
Client then sends:
3.
Client then sends:
```
```
...
@@ -119,6 +120,7 @@ Procedure:
...
@@ -119,6 +120,7 @@ Procedure:
}
}
}
}
```
```
4.
Client then sends:
4.
Client then sends:
```
```
...
@@ -128,6 +130,7 @@ Procedure:
...
@@ -128,6 +130,7 @@ Procedure:
}
}
}
}
```
```
5.
Client then sends:
5.
Client then sends:
```
```
...
@@ -137,9 +140,10 @@ Procedure:
...
@@ -137,9 +140,10 @@ Procedure:
}
}
}
}
```
```
6.
Client halfCloses
Asserts:
6.
Client half-closes
Client asserts:
*
call was successful
*
call was successful
*
response aggregated_payload_size is 74922
*
response aggregated_payload_size is 74922
...
@@ -172,7 +176,7 @@ Procedure:
...
@@ -172,7 +176,7 @@ Procedure:
}
}
```
```
A
sserts:
Client a
sserts:
*
call was successful
*
call was successful
*
exactly four responses
*
exactly four responses
*
response payloads are COMPRESSABLE
*
response payloads are COMPRESSABLE
...
@@ -202,6 +206,7 @@ Procedure:
...
@@ -202,6 +206,7 @@ Procedure:
}
}
}
}
```
```
2.
After getting a reply, it sends:
2.
After getting a reply, it sends:
```
```
...
@@ -215,6 +220,7 @@ Procedure:
...
@@ -215,6 +220,7 @@ Procedure:
}
}
}
}
```
```
3.
After getting a reply, it sends:
3.
After getting a reply, it sends:
```
```
...
@@ -228,6 +234,7 @@ Procedure:
...
@@ -228,6 +234,7 @@ Procedure:
}
}
}
}
```
```
4.
After getting a reply, it sends:
4.
After getting a reply, it sends:
```
```
...
@@ -242,7 +249,9 @@ Procedure:
...
@@ -242,7 +249,9 @@ Procedure:
}
}
```
```
Asserts:
5.
After getting a reply, client half-closes
Client asserts:
*
call was successful
*
call was successful
*
exactly four responses
*
exactly four responses
*
response payloads are COMPRESSABLE
*
response payloads are COMPRESSABLE
...
@@ -261,7 +270,7 @@ Server features:
...
@@ -261,7 +270,7 @@ Server features:
Procedure:
Procedure:
1.
Client calls FullDuplexCall and then half-closes
1.
Client calls FullDuplexCall and then half-closes
A
sserts:
Client a
sserts:
*
call was successful
*
call was successful
*
exactly zero responses
*
exactly zero responses
...
@@ -300,7 +309,7 @@ Procedure:
...
@@ -300,7 +309,7 @@ Procedure:
}
}
```
```
A
sserts:
Client a
sserts:
*
call was successful
*
call was successful
*
received SimpleResponse.username equals the value of
`--default_service_account`
flag
*
received SimpleResponse.username equals the value of
`--default_service_account`
flag
*
received SimpleResponse.oauth_scope is in
`--oauth_scope`
*
received SimpleResponse.oauth_scope is in
`--oauth_scope`
...
@@ -328,7 +337,7 @@ Server features:
...
@@ -328,7 +337,7 @@ Server features:
*
[
Echo OAuth Scope
][]
*
[
Echo OAuth Scope
][]
Procedure:
Procedure:
1.
Client configures the channel to use ServiceAccountCredentials
.
1.
Client configures the channel to use ServiceAccountCredentials
2.
Client calls UnaryCall with:
2.
Client calls UnaryCall with:
```
```
...
@@ -343,7 +352,7 @@ Procedure:
...
@@ -343,7 +352,7 @@ Procedure:
}
}
```
```
A
sserts:
Client a
sserts:
*
call was successful
*
call was successful
*
received SimpleResponse.username is in the json key file read from
*
received SimpleResponse.username is in the json key file read from
`--service_account_key_file`
`--service_account_key_file`
...
@@ -370,7 +379,7 @@ Server features:
...
@@ -370,7 +379,7 @@ Server features:
*
[
Echo OAuth Scope
][]
*
[
Echo OAuth Scope
][]
Procedure:
Procedure:
1.
Client configures the channel to use JWTTokenCredentials
.
1.
Client configures the channel to use JWTTokenCredentials
2.
Client calls UnaryCall with:
2.
Client calls UnaryCall with:
```
```
...
@@ -384,7 +393,7 @@ Procedure:
...
@@ -384,7 +393,7 @@ Procedure:
}
}
```
```
A
sserts:
Client a
sserts:
*
call was successful
*
call was successful
*
received SimpleResponse.username is in the json key file read from
*
received SimpleResponse.username is in the json key file read from
`--service_account_key_file`
`--service_account_key_file`
...
@@ -422,7 +431,7 @@ Server features:
...
@@ -422,7 +431,7 @@ Server features:
Procedure:
Procedure:
1.
Client uses the auth library to obtain an authorization token
1.
Client uses the auth library to obtain an authorization token
2.
Client configures the channel to use AccessTokenCredentials with the access token obtained in step 1
.
2.
Client configures the channel to use AccessTokenCredentials with the access token obtained in step 1
3.
Client calls UnaryCall with the following message
3.
Client calls UnaryCall with the following message
```
```
...
@@ -431,8 +440,8 @@ Procedure:
...
@@ -431,8 +440,8 @@ Procedure:
fill_oauth_scope: true
fill_oauth_scope: true
}
}
```
```
A
sserts:
Client a
sserts:
*
call was successful
*
call was successful
*
received SimpleResponse.username is in the json key file used by the auth
*
received SimpleResponse.username is in the json key file used by the auth
library to obtain the authorization token
library to obtain the authorization token
...
@@ -464,10 +473,10 @@ Server features:
...
@@ -464,10 +473,10 @@ Server features:
Procedure:
Procedure:
1.
Client uses the auth library to obtain an authorization token
1.
Client uses the auth library to obtain an authorization token
2.
Client configures the channel with just SSL credentials
.
2.
Client configures the channel with just SSL credentials
3.
Client calls UnaryCall, setting per-call credentials to
3.
Client calls UnaryCall, setting per-call credentials to
AccessTokenCredentials with the access token obtained in step 1. The request
is
AccessTokenCredentials with the access token obtained in step 1. The request
the following message
is
the following message
```
```
{
{
...
@@ -475,8 +484,8 @@ Procedure:
...
@@ -475,8 +484,8 @@ Procedure:
fill_oauth_scope: true
fill_oauth_scope: true
}
}
```
```
A
sserts:
Client a
sserts:
*
call was successful
*
call was successful
*
received SimpleResponse.username is in the json key file used by the auth
*
received SimpleResponse.username is in the json key file used by the auth
library to obtain the authorization token
library to obtain the authorization token
...
@@ -496,8 +505,14 @@ Server features:
...
@@ -496,8 +505,14 @@ Server features:
*
[
Echo Metadata
][]
*
[
Echo Metadata
][]
Procedure:
Procedure:
1.
While sending custom metadata (ascii + binary) in the header, client calls
1.
The client attaches custom metadata with the following keys and values:
UnaryCall with:
```
key: "x-grpc-test-echo-initial", value: "test_initial_metadata_value"
key: "x-grpc-test-echo-trailing-bin", value: 0xababab
```
to a UnaryCall with request:
```
```
{
{
...
@@ -508,23 +523,41 @@ Procedure:
...
@@ -508,23 +523,41 @@ Procedure:
}
}
}
}
```
```
The client attaches custom metadata with the following keys and values:
2.
The client attaches custom metadata with the following keys and values:
```
```
key: "x-grpc-test-echo-initial", value: "test_initial_metadata_value"
key: "x-grpc-test-echo-initial", value: "test_initial_metadata_value"
key: "x-grpc-test-echo-trailing-bin", value: 0xababab
key: "x-grpc-test-echo-trailing-bin", value: 0xababab
```
```
2.
Client repeats step 1. with FullDuplexCall instead of UnaryCall.
Asserts:
to a FullDuplexCall with request:
```
{
response_type: COMPRESSABLE
response_size: 314159
payload:{
body: 271828 bytes of zeros
}
}
```
and then half-closes
Client asserts:
*
call was successful
*
call was successful
*
metadata with key
`"x-grpc-test-echo-initial"`
and value
`"test_initial_metadata_value"`
is received in the initial metadata.
*
metadata with key
`"x-grpc-test-echo-initial"`
and value
*
metadata with key
`"x-grpc-test-echo-trailing-bin"`
and value
`0xababab`
is received in the trailing metadata.
`"test_initial_metadata_value"`
is received in the initial metadata for calls
in Procedure steps 1 and 2.
*
metadata with key
`"x-grpc-test-echo-trailing-bin"`
and value
`0xababab`
is
received in the trailing metadata for calls in Procedure steps 1 and 2.
### status_code_and_message
### status_code_and_message
This test verifies unary calls succeed in sending messages, and propagate
s
back
This test verifies unary calls succeed in sending messages, and propagate back
status code and message sent along with the messages.
status code and message sent along with the messages.
Server features:
Server features:
...
@@ -543,12 +576,26 @@ Procedure:
...
@@ -543,12 +576,26 @@ Procedure:
}
}
}
}
```
```
2.
Client repeats step 1. with FullDuplexCall instead of UnaryCall.
2.
Client calls FullDuplexCall with:
```
{
response_status:{
code: 2
message: "test status message"
}
}
```
and then half-closes
Asserts:
*
received status code is the same with sent code
Client asserts:
*
received status message is the same with sent message
*
received status code is the same as the sent code for both Procedure steps 1
and 2
*
received status message is the same as the sent message for both Procedure
steps 1 and 2
### unimplemented_method
### unimplemented_method
...
@@ -556,15 +603,19 @@ Status: Ready for implementation. Blocking beta.
...
@@ -556,15 +603,19 @@ Status: Ready for implementation. Blocking beta.
This test verifies calling unimplemented RPC method returns the UNIMPLEMENTED status code.
This test verifies calling unimplemented RPC method returns the UNIMPLEMENTED status code.
Server features:
N/A
Procedure:
Procedure:
*
Client calls
`grpc.testing.UnimplementedService/UnimplementedCall`
with an empty request (defined as
`grpc.testing.Empty`
):
*
Client calls
`grpc.testing.UnimplementedService/UnimplementedCall`
with an
empty request (defined as
`grpc.testing.Empty`
):
```
```
{
{
}
}
```
```
A
sserts:
Client a
sserts:
*
received status code is 12 (UNIMPLEMENTED)
*
received status code is 12 (UNIMPLEMENTED)
*
received status message is empty or null/unset
*
received status message is empty or null/unset
...
@@ -580,7 +631,7 @@ Procedure:
...
@@ -580,7 +631,7 @@ Procedure:
1.
Client starts StreamingInputCall
1.
Client starts StreamingInputCall
2.
Client immediately cancels request
2.
Client immediately cancels request
A
sserts:
Client a
sserts:
*
Call completed with status CANCELLED
*
Call completed with status CANCELLED
### cancel_after_first_response
### cancel_after_first_response
...
@@ -606,9 +657,10 @@ Procedure:
...
@@ -606,9 +657,10 @@ Procedure:
}
}
}
}
```
```
2.
After receiving a response, client cancels request
2.
After receiving a response, client cancels request
A
sserts:
Client a
sserts:
*
Call completed with status CANCELLED
*
Call completed with status CANCELLED
### timeout_on_sleeping_server
### timeout_on_sleeping_server
...
@@ -620,7 +672,8 @@ Server features:
...
@@ -620,7 +672,8 @@ Server features:
*
[
FullDuplexCall
][]
*
[
FullDuplexCall
][]
Procedure:
Procedure:
1.
Client calls FullDuplexCall with the following request and sets its timeout to 1ms.
1.
Client calls FullDuplexCall with the following request and sets its timeout
to 1ms
```
```
{
{
...
@@ -630,7 +683,9 @@ Procedure:
...
@@ -630,7 +683,9 @@ Procedure:
}
}
```
```
Asserts:
2.
Client waits
Client asserts:
*
Call completed with status DEADLINE_EXCEEDED.
*
Call completed with status DEADLINE_EXCEEDED.
### concurrent_large_unary
### concurrent_large_unary
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment