|
1 | 1 | # Parsec Mock
|
2 | 2 |
|
3 |
| -This repository contains a mock service to test clients. |
| 3 | +This repository contains a mock service to test clients, and a test data generator to create test data files for the mock service, or to be used in testing of the parsec service, or parsec clients. |
| 4 | + |
4 | 5 | See [this issue](https://github.com/parallaxsecond/parsec/issues/350) which describes the
|
5 | 6 | proposal.
|
6 | 7 |
|
| 8 | +# Prerequisites |
| 9 | +To run the utilities in this repository, you will need python3 and pip installing. |
| 10 | + |
| 11 | +To install package prerequisites, run the following from this folder: |
| 12 | + |
| 13 | +```bash |
| 14 | +pip install -r requirements.txt |
| 15 | +``` |
| 16 | +# Usage |
| 17 | +## Run Mock Service |
| 18 | +**TBD** |
| 19 | + |
| 20 | +## Generate Test Data |
| 21 | +To generate test data from test specs, run |
| 22 | + |
| 23 | +``` |
| 24 | +python generator/generator.py |
| 25 | +``` |
| 26 | + |
| 27 | +This will parse the test specs in generator/testspecs and create test data in testdata/. |
| 28 | + |
| 29 | +# Test Data |
| 30 | +The generator/generator.py script creates test data files in the testdata folder. These test data files are intended for use, either with the mock service supplied here, or in other mock services that may be developed for the parsec service or parsec clients. The test data files consist of the [test spec](#test-spec-format) (useful for the writer of a unit test), and test data, which contains base 64 encodes strings for a parsec request and a corresponding result. |
| 31 | + |
| 32 | +The overall test data file format is, therefore: |
| 33 | + |
| 34 | +```yaml |
| 35 | +spec: |
| 36 | + # for format see below |
| 37 | +test_data: |
| 38 | + request: EKfAXh4AAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAA |
| 39 | + result: EKfAXh4AAQAAAAAAAAAAAAAAAAAAAAIAAAAAAAEAAAAAAAAACAE= |
| 40 | +``` |
| 41 | +## Expected Use Of Test Data |
| 42 | +This repository does not dictate how the test data should be used by parsec client developers, but it was developed with the following use case in mind: |
| 43 | +
|
| 44 | +A client developer wants to test a parsec request in their client. |
| 45 | +- They select an appropriate test data file that fulfils the needs of their test (or creates a new one in this repository and uses that) |
| 46 | +- They write client code that should generate a message to match the request section of the [test spec](#test-spec-format). |
| 47 | +- They configure a mock service (the one here or a custom one) to expect the data defined in the test_data.request part of the test data file as well as the data to send if that request is received and what to send if it is not. |
| 48 | +- They stimulate their client under test to send the request message to the mock service. |
| 49 | +- The mock service will check to see if the request message it received matches the expected value (this is an exact byte match). |
| 50 | + - If the match was successful, then it will return the configured match response |
| 51 | + - Otherwise, it will return the configured non-match response |
| 52 | +- The client under test will attempt to decode the response. The results can be checked by the test code. |
| 53 | +- If the spec.response.parse_should_succeed field is set to true, then the test code *should* expect a successful parse of the response data. Otherwise, it *should* expect the parsing to fail. |
| 54 | +
|
| 55 | +
|
| 56 | +## Writing Tests |
| 57 | +To write a new test, a developer should create a test spec file in the generator/testspecs folder, using the [format below](#test-spec-format). |
| 58 | +
|
| 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 | + |
| 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 | + |
| 63 | +An example generator for a list opcodes test is shown below: |
| 64 | + |
| 65 | +```python |
| 66 | +def gen_list_opcodes_auth_direct(): |
| 67 | + op = protobuf.list_opcodes_pb2.Operation() |
| 68 | + op.provider_id = 1 |
| 69 | +
|
| 70 | + result = protobuf.list_opcodes_pb2.Result() |
| 71 | + result.opcodes.extend([1,3,2]) |
| 72 | + return (op.SerializeToString(), result.SerializeToString()) |
| 73 | +``` |
| 74 | +The generated protocol buffers python library files are in generator/protobuf. |
| 75 | + |
| 76 | +Finally, the developer should add an entry to the generator dictionary at the bottom of the ```generator/generator_lib.py``` file. The key must correspond to the value in the test spec's spec.generator field. The value in the generator dictionary must be the new generator function name. e.g.: |
| 77 | + |
| 78 | +```python |
| 79 | +generators = { |
| 80 | + 'ping_no_auth': gen_ping_no_auth, |
| 81 | + 'list_opcodes_auth_direct': gen_list_opcodes_auth_direct, |
| 82 | +} |
| 83 | +``` |
| 84 | +**NOTE** A generator function can be used in multiple test specs, if required. |
| 85 | + |
| 86 | +## Test Spec Format |
| 87 | + |
| 88 | +Test specs are defined as YAML. An example file is shown below: |
| 89 | + |
| 90 | +```yaml |
| 91 | +# Copyright 2021 Contributors to the Parsec project. |
| 92 | +# SPDX-License-Identifier: Apache-2.0 |
| 93 | +spec: |
| 94 | + name: list_opcodes_auth_direct |
| 95 | + generator: list_opcodes_auth_direct |
| 96 | + description: List opcodes using direct authentication |
| 97 | + request: |
| 98 | + header: |
| 99 | + magic_number: 0x5EC0A710 |
| 100 | + header_size: 0x1E |
| 101 | + major_version_number: 0x01 |
| 102 | + minor_version_number: 0x00 |
| 103 | + flags: 0x0000 |
| 104 | + provider: 0x00 |
| 105 | + session_handle: 0x0000000000000000 |
| 106 | + content_type: 0x00 |
| 107 | + accept_type: 0x00 |
| 108 | + auth_type: 0x00 |
| 109 | + content_length: auto |
| 110 | + auth_length: auto |
| 111 | + opcode: 0x00000009 |
| 112 | + status: 0x0000 |
| 113 | + body_description: provider id 0x01 |
| 114 | + auth: |
| 115 | + type: direct |
| 116 | + app_name: jimbob |
| 117 | + result: |
| 118 | + header: |
| 119 | + magic_number: 0x5EC0A710 |
| 120 | + header_size: 0x1E |
| 121 | + major_version_number: 0x01 |
| 122 | + minor_version_number: 0x00 |
| 123 | + flags: 0x0000 |
| 124 | + provider: 0x00 |
| 125 | + session_handle: 0x0000000000000000 |
| 126 | + content_type: 0x00 |
| 127 | + accept_type: 0x00 |
| 128 | + auth_type: 0x00 |
| 129 | + content_length: auto |
| 130 | + auth_length: auto |
| 131 | + opcode: 0x00000009 |
| 132 | + status: 0x0000 |
| 133 | + body_description: list opcodes result [1,3,2] |
| 134 | + auth: |
| 135 | + type: direct |
| 136 | + app_name: jimbob |
| 137 | +
|
| 138 | +``` |
| 139 | +The whole test spec is defined in the spec: object in the file. In that spec, the fields are: |
| 140 | +| Field | Description | |
| 141 | +| --- | --- | |
| 142 | +| name | The name of the test spec. Used to name the output test data file | |
| 143 | +| generator | The lookup for the operation and result generator in the generator library. See [writing tests](#writing-tests).| |
| 144 | +| description | Description of test, not used in generation | |
| 145 | +| request | Settings for configuring the request data for the test data file | |
| 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). | |
| 147 | +| request.header.content_length | If this field has the value ```auto``` then its value is calculated from the generated request content. If the value is a number, then that value is used in the field instead. | |
| 148 | +| request.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. | |
| 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. | |
| 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. | |
| 151 | +| request.auth.app_name | Used to populate the auth section of the message when ```direct``` authentication is selected | |
| 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 | |
| 159 | + |
| 160 | + |
| 161 | + |
7 | 162 | # License
|
8 | 163 |
|
9 | 164 | The software is provided under Apache-2.0. Contributions to this project are accepted under the same
|
|
0 commit comments