BRAVA calls one or more resources in the tested server and tests the response.
First, the /calls resource is requested. If the response is valid, the list of available calls is parsed.
Following a predefined order, BRAVA requests the available resources. For every resource, the status code, content type and JSON schema is checked. Each resource has a specific schema defined. This checks the structure, parameter name and parameter types.
For example, the /germplasm-search test requires the response data object to contain a germplasmDbId attribute with a string value, among others.
We created the JSON schemas using the official BrAPI specifications. They are available here, feel free to check them and use them in your own tests. They may differ from the official specifications because we update them manually. Let us know of any inconsistencies in the issue tracker.
Some tests also make sure the data is consistent across resources. This works by storing a few values from the response. The specific parameters that are saved depend on the test. The server will make a request to other resources using these values as input.
This way you can automatically test some resources that would require manual input for certain parameters.
For example, a call to /markerprofiles could store markerprofileDbId. This value can be used as input for /markerprofiles/{markerprofileDbId}.
