You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: README.md
+9-11
Original file line number
Diff line number
Diff line change
@@ -58,7 +58,7 @@ To write a new test, a developer should create a test spec file in the generator
58
58
59
59
They then need to write a generator function in ```generator/generator_lib.py```. This generator function takes no arguments, and should output a tuple of python binary strings.
60
60
61
-
The first element of the tuple should be the protocol buffer encoded value of the requestmessage that is described in the spec.request.body_description field of the test spec. The second element of the tuple should be the protocol buffer encoded value of the result message that is described in the spec.result.body_description field of the test spec.
61
+
The first element of the tuple should be the protocol buffer encoded value of the request's *operation* message that is described in the spec.request.body_description field of the test spec. The second element of the tuple should be the protocol buffer encoded *result* value of the response message that is described in the spec.result.body_description field of the test spec.
62
62
63
63
An example generator for a list opcodes test is shown below:
64
64
@@ -134,14 +134,13 @@ spec:
134
134
auth:
135
135
type: direct
136
136
app_name: jimbob
137
-
expected_parse_result: fail_auth
138
137
139
138
```
140
139
The whole test spec is defined in the spec: object in the file. In that spec, the fields are:
141
140
| Field | Description |
142
141
| --- | --- |
143
142
| name | The name of the test spec. Used to name the output test data file |
144
-
| generator | The lookup for the request and response generator in the generator library. See [writing tests](#writing-tests).|
143
+
| generator | The lookup for the operation and result generator in the generator library. See [writing tests](#writing-tests).|
145
144
| description | Description of test, not used in generation |
146
145
| request | Settings for configuring the request data for the test data file |
147
146
| request.header | Field values for the request header. Meanings of these files and valid values can be found in the [parsec book](https://parallaxsecond.github.io/parsec-book/parsec_client/wire_protocol.html). |
@@ -150,14 +149,13 @@ The whole test spec is defined in the spec: object in the file. In that spec, t
150
149
| request.body_description | A free form description of the contents of the request content. Used for test writers (and generator writers) to understand how to construct the request object. This field is not used by the test generator. |
151
150
| request.auth.type | This can either be ```none```, which will cause the auth section of the message to be empty (equivalent of the No Authentication type of authentication); or it can be ```direct```, which will cause the auth section of the message to contain authentication data corresponding to the format for Direct Authentication. If ```direct``` is set, then the request.auth.app_name field must be set. Note that this field does not cause the header auth_type field to be set. |
152
151
| request.auth.app_name | Used to populate the auth section of the message when ```direct``` authentication is selected |
153
-
| result | Settings for configuration the result data for the test data file |
154
-
| result.header | Field values for the result header. Meanings of these files and valid values can be found in the [parsec book](https://parallaxsecond.github.io/parsec-book/parsec_client/wire_protocol.html). |
155
-
| result.header.content_length | If this field has the value ```auto``` then its value is calculated from the generated result content. If the value is a number, then that value is used in the field instead |
156
-
| result.header.auth_length | If this field has the value ```auto``` then its value is calculated from the generated auth content. If the value is a number, then that value is used in the field instead. |
157
-
| result.body_description | A free form description of the contents of the result content. Used for test writers (and generator writers) to understand how to construct the request object. This field is not used by the test generator. |
158
-
| result.auth.type | This can either be ```none```, which will cause the auth section of the message to be empty (equivalent of the No Authentication type of authentication); or it can be ```direct```, which will cause the auth section of the message to contain authentication data corresponding to the format for Direct Authentication. If ```direct``` is set, then the result.auth.app_name field must be set. Note that this field does not cause the header auth_type field to be set. **NOTE:** A Parsec client would not send authentication data in a result message, but this spec format allows test authors to create the message as they wish to excersice the parsec client code. |
159
-
| result.auth.app_name | Used to populate the auth section of the message when ```direct``` authentication is selected |
160
-
| result.expected_parse_result | Used to indicate whether a client being tested with this data should successfully be parsed (even if it is returning a failure status code). If the message is valid according to the parsec interface specification, this field should have the valid ```succeed```. If the message is invalid, it should have the values of ```fail_header``` if the header is invalid; ```fail_auth``` if the authentication data is invlid, or ```fail_content``` if the content is invalid. Further values may be added to this ennum in the future. |
152
+
| response | Settings for configuration the response data for the test data file |
153
+
| response.header | Field values for the response header. Meanings of these files and valid values can be found in the [parsec book](https://parallaxsecond.github.io/parsec-book/parsec_client/wire_protocol.html). |
154
+
| response.header.content_length | If this field has the value ```auto``` then its value is calculated from the generated response content. If the value is a number, then that value is used in the field instead |
155
+
| response.header.auth_length | If this field has the value ```auto``` then its value is calculated from the generated auth content. If the value is a number, then that value is used in the field instead. |
156
+
| response.body_description | A free form description of the contents of the response content. Used for test writers (and generator writers) to understand how to construct the result object. This field is not used by the test generator. |
157
+
| response.auth.type | This can either be ```none```, which will cause the auth section of the message to be empty (equivalent of the No Authentication type of authentication); or it can be ```direct```, which will cause the auth section of the message to contain authentication data corresponding to the format for Direct Authentication. If ```direct``` is set, then the result.auth.app_name field must be set. Note that this field does not cause the header auth_type field to be set. **NOTE:** A Parsec client would not send authentication data in a result message, but this spec format allows test authors to create the message as they wish to excersice the parsec client code. |
158
+
| response.auth.app_name | Used to populate the auth section of the message when ```direct``` authentication is selected |
0 commit comments