passivsystems / protean Goto Github PK

we currently use keys from request form-params or JSON body payload, use values too to give accurate sample curl commands and usage docs

request and response keys could be aligned with those of Ring principle of least surprise etc

verify keys/structure in the case of json payloads perhaps

we need to be able to describe conditions for success or failure of an endpoint result in the codex

ie codex specifies that data is in location header but real service returns plain text body
currently auto integration test fails with status 500 without pinpointing the reason for the error

currently there can be some repetition... maybe useful to define a component which can be stitched throughout codex for example a :req element for post, with json and bearer token

set sensible default of method before enabling request method override in codex

can't seem to specify just a sequence of services to test

java.lang.IllegalArgumentException: No value supplied for key:

real API's may return a multitude of status codes and mime types, handle gracefully

enable restful control of status and probability on project paths - currently only configurable by hotswapping project configuration

no provision made for cases where the difference between two variants is the content of a request body or presence of parameter(s)

we can simulate and integration test based on a fixed request body shape, but when a document is passed as payload it may be a generic bag of key/value pairs which can change in shape

how can we represent this in a codex for testing ? we are ok for simulation - we just omit specifying anything in the request

need to inform client which tests were not called due to unavailable seed data or unavailable prior results

we know how to generate command to call paths/endpoints, we could easily substitute host/port combinations to test the real things

POST PUT etc

Location header
Body text/plain
Body application/json (which field ?)

replace with some kind of generic marker xyz ?

must preserve backwards compatibility over simulation, auto doc, sim test, api test and not impede work on real service data driven work

currently in analysis and docs production code, should be in one place used by both

could generate info on request method, expected params / headers etc

provide a map of what services do