1 # Acceptance Testing Blueprints
3 ## What is BP User Acceptance Tests (UATs)?
5 UATs aims to fully test the BlueprintsProcessor (BPP) using a blueprint.
6 The BPP runs in an almost production-like configuration with some minor exceptions:
8 - It uses an embedded, in-memory, and initially empty H2 database, running in MySQL/MariaDB compatibility mode;
9 - All external services are mocked.
13 The UATs are declarative, data-driven tests implemented in YAML 1.1 documents.
14 This YAML files express:
16 - Sequence of requests to be sent to the BPP for every process;
17 - The expected BPP responses;
18 - For every used external service:
19 - The `selector` used internally to instantiate the rest client;
20 - A variable set of expected requests and corresponding responses.
22 The UAT engine will perform the following validations:
25 - The payloads in the external services requests and it's content type.
27 ## Adding your BP to the suite of UATs
29 To add a new BP to the UAT suite, all you need to do is:
30 1. Add your blueprint folder under
31 CDS project's `components/model-catalog/blueprint-model/uat-blueprints` directory;
32 2. Create a `Tests/uat.yaml` document under your BP folder.
34 ## `uat.yaml` reference
36 The structure of an UAT YAML file could be documented using the Protobuf language as follows:
44 required string name = 1;
45 required Json request = 2;
46 required Json expectedResponse = 3;
47 optional Json responseNormalizerSpec = 4;
51 required string method = 1;
52 required Path path = 2;
53 optional string contentType = 3 [default = None];
54 optional Json body = 4;
58 optional int32 status = 1 [default = 200];
59 optional Json body = 2;
63 required Request request = 1;
64 optional Response response = 2;
65 repeated Response responses = 3;
68 message ExternalService {
69 required string selector = 1;
70 repeated Expectation expectations = 2; // min cardinality = 1
73 repeated Process processes = 1; // min cardinality = 1
74 repeated ExternalService externalServices = 2; // min cardinality = 0
79 The optional `responseNormalizerSpec` specifies transformations that may be needed to apply to the response
80 returned by BPP to get a full JSON representation. For example, it's possible to convert an string field "outer.inner"
81 into JSON using the following specification:
84 responseNormalizerSpec:
86 inner: ?from-json(.outer.inner)
90 The "?" must prefix every expression that is NOT a literal string. The `from-json()` function and
91 many others are documented [here](https://github.com/schibsted/jslt/blob/0.1.8/functions.md).
93 ### Skeleton of a basic `uat.yaml`
101 commonHeader: &commonHeader
103 requestId: "123456-1000"
104 subRequestId: sub-123456-1000
105 actionIdentifiers: &assign-ai
106 blueprintName: configuration_over_restconf
107 blueprintVersion: "1.0.0"
108 actionName: config-assign
113 commonHeader: *commonHeader
114 actionIdentifiers: *assign-ai
117 eventType: EVENT_COMPONENT_EXECUTED
125 resource-assignment-params:
138 status: 200 # optional, 200 is the default value
139 body: # optional, default is an empty content
144 content-type: application/json
151 ### Composite URI paths
153 In case your YAML document contains many URI path definitions, it's recommended to keep the duplications
154 as low as possible in order to ease the document maintenance, and avoid inconsistencies.
156 Since YAML doesn't provide a standard mechanism to concatenate strings,
157 the UAT engine implements an ad-hoc mechanism based on multi-level lists.
158 Please note that currently this mechanism is only applied to URI paths.
160 To exemplify how it works, let's take the case of eliminating duplications when defining multiple OpenDaylight URLs.
162 You might start using the following definitions:
164 nodeId: &nodeId "new-netconf-device"
167 path: &configUri [restconf/config, &nodeIdentifier [network-topology:network-topology/topology/topology-netconf/node, *nodeId]]
170 path: [restconf/operational, *nodeIdentifier]
173 path: [*configUri, &configletResourcePath yang-ext:mount/mynetconf:netconflist]
176 The UAT engine will expand the above multi-level lists, resulting on the following URI paths:
180 path: restconf/config/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device
183 path: restconf/operational/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device
186 path: restconf/config/network-topology:network-topology/topology/topology-netconf/node/new-netconf-device/yang-ext:mount/mynetconf:netconflist
191 Copyright (C) 2019 Nordix Foundation.
193 Licensed under the Apache License, Version 2.0 (the "License");
194 you may not use this file except in compliance with the License.
195 You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0
197 Unless required by applicable law or agreed to in writing, software
198 distributed under the License is distributed on an "AS IS" BASIS,
199 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
200 See the License for the specific language governing permissions and
201 limitations under the License.