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.
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.
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