A tester or developer uses a web browser to access the console. The console manages the virtual service. The system under test (application under test) connects directly to the virtual service on different ports.
Here is an example of how that could look like for a scenario where the virtual service is replaying files.
Virtual service replaying files from a request directory to a response directoryFirst, go to Files in the top navigation bar and then click Add/Edit.
Fill in the Request/Response fields and click Save to configure a mapping.
After saving the mapping, it will appear in the list of mappings.
Clicking the edit button 
will
allow you to edit an existing mapping.
The request priority can be set in order to set up a preference order for matching mappings.
The highest priority value is 1. If two or more mappings both match a request, the mapping with the higher priority will be used to provide the response. The default priority is 5.
This can be useful, if you want a "catch-all" mapping that returns a general response for most requests and specific mappings on top that return more specific responses.
When Traffic Parrot notices a request files, it will try to simulate the system it is replacing by creating a response file in the specified directory. To decide what is the name and content of the response file, it will go through all the request to response mappings it has available to find the response file definition. For more details how request matching works, see Request matching.
There are several matchers available to match request files, depending on the attribute.
| Matcher name | Matcher Id | Description |
|---|---|---|
| equal to | equalTo | Check that filename of the request file is equal to the one specified in the mapping |
| contains | contains | Check that the filename of the request file contains the sequence of characters specified in the mapping |
| matches regex | matches | Check that the filename of the request file matches the regexp specified in the mapping |
| does not match regexp | doesNotMatch | Check that the filename of the request file does not match the regexp specified in the mapping |
| Matcher name | Matcher Id | Description |
|---|---|---|
| any | any | Any received request file contents will match. |
| equal to | equalTo | Check that the received request file contents is equal to the request body specified in the mapping |
| contains | contains | Check that the received request file contains the sequence of characters specified in the mapping |
| matches regex | matches | Check that the received request file contents matches the regexp specified in the mapping |
| does not match regexp | doesNotMatch | Check that the received request file contents does not match the regexp specified in the mapping |
| equal to JSON | equalToJson | Check that the received request file contents is JSON and that it is equal to the request body JSON specified in the mapping |
| matches JSON | matchesJson |
Check that the received request file contents matches (allowing for special wildcard tokens) JSON specified in the mapping.
Tokens allowed:
For example a "matches JSON" request body matcher:
{
"name": "{{ anyValue }}",
"lastName": "{{ anyValue }}",
"age": "{{ anyNumber }}",
"children": "{{ anyElements }}"
}
will match a request body:
{
"name": "Bob",
"lastName": "Smith",
"age": 37,
"children": [{"name": "sam"}, {"name": "mary"}]
}
|
| matches JSONPath | matchesJsonPath | Check that the received request file contents is JSON and that it matches JSONPath
specified in the mapping. For example, if we use the following expression as the request body matcher
$[?(@.xyz.size() == 2)]it will match this request body: {"xyz":[{"a":true}, {"b":false}]}
but will NOT match this one:
{"xyz":["a":true, "b":false, "c":true]}
|
| equal to XML | equalToXml | Check that the received request file contents is XML and that it is equal to the request body XML specified in the mapping |
| matches XML | matchesXml |
Check that the received request file contents matches (allowing for special wildcard tokens) XML specified in the mapping.
Tokens allowed:
For example a matches XML request body matcher:
<example>
<name>{{ anyValue }}</name>
<age>{{ anyNumber }}</age>
<children><tp:AnyElements/></children>
</example>
will match a request body:
<example> <name>Sam</name> <age>29</age> <children><child name="bob"/></children> </example> |
| matches XPath | matchesXPath | Check that the received request file contents is XML and that it matches XPath
specified in the mapping. For example, if we use the following expression as the request body matcher
/xyz[count(abc) = 2]it will match this request body: <xyz><abc/><abc/></xyz>but will NOT match this one: <xyz><abc/></xyz> |
To record from or replay to file systems you will need to tell Traffic Parrot which root directories to use.
Those root directories are displayed in the dropdown menus on the record and replay panels, for example:
All directories that are configured when e.g. adding a mapping are relative to the selected root directory.
To define a new root directories that will be available in the dropdown in the record and replay panels:[
{
"id": "1",
"name": "C Drive",
"rootDirectory": "C:\\some\\root\\directory"
},
{
"id": "2",
"name": "Network Drive",
"rootDirectory": "\\network\\share"
}
]
In the current Traffic Parrot version you edit root directories directly in the root-directories.json file. In near future you will be able to do it via the Web UI as well.
trafficparrot.virtualservice.rootDirectoriesUrl=classpath:root-directories.jsonto for example
trafficparrot.virtualservice.rootDirectoriesUrl=file:/home/john/git/project/root-directories.jsonThis can be useful if you would like to version control it with your application source code.
This documentation is for an old version of Traffic Parrot. There is a more recent Traffic Parrot version available for download at trafficparrot.com