ETS reports error on 400 response for bad input values

[jerstlouis]

Describe the bug The ETS sends execution requests with bad input values not conforming to schema, yet reports a failure on unexpected 400 response on these bad inputs.

Expected behavior The server should expect a 400 error if it sends bad values either not conforming to schema, or values that may conform to schema but for some reason are invalid when not using a pre-determined example.

Additional context In these particular cases of the echo process, the ETS is using "teststring" where a date-time and a binary GeoTIFF image are expected.

The ETS also uses {"value":"teststring"} as a measure input where an object with measurement and uom are the expected required fields of an object e.g., {"value": { "measurement": 10, "uom": "[ogc-uom:metre]" } }.

The ETS also includes an extra pause input that is not declared in the process description, and reports an failure on the server returning a 400 error about it.

[bpross-52n]

We fixed the wrong behavior of setting the teststring value for inputs like datetime. Now it is only used for plain string inputs. Other input types are not taken into account.

[dstenger]

@bpross-52n Can you please improve the failure message of the test suite when a not supported input type is used? Also, the documentation of the test suite should be enhanced listing the supported input types.

[dstenger]

Can you please update the skipException to a test failure and update the documentation saying that the tested process must support any of the listed input types (e.g. in a preconditions section)?