fabmob / playground-standard-covoiturage Goto Github PK

The command "pscovoit test" uses the URL to pass the query URL. This flag is not checked, so that a missing --url flag results in unclear error message.

In addition to checking that an URL is passed, it would probably be relevant to pass the URL as argument, and not as flag, which is anyway more common in other tools (curl, restish,...)

The example in kin-openapi's README only works if the right server is specified in the OpenAPI spec (which will not be the case), or if the server is equal to the host, which will not always be the case.

Any test on a server that is not also the uri host currently fails on format assertion with following error :
no matching operation was found

The server needs probably to be set by hand (populate doc.Servers).

The count parameter is used in an unsafe way. Probably a "<=" that should be a "<"

To reproduce :

go run main.go test --url "http://localhost:1323/driver_journeys?departureLat=48.8588548&departureLng=2.264463&arrivalLat=47.8733876&arrivalLng=1.8296428&departureDate=1668608335&timeDelta=100000&departureRadius=10&arrivalRadius=10&count=2"

Error:

runtime error: slice bounds out of range [:2] with capacity 0
goroutine 19 [running]:

Even in verbose mode, the output is not always enough for debugging purposes.

A --debug flag would be useful, for instance to print complete request and response to troubleshoot problems.

Parsing an URL with missing scheme with golang url package may not fail, but leads nonetheless to unwanted behavior and obscure error messages.

For this reason, the scheme should be checked beforehand.

In the current CI pipeline, the server is launched in background before the test queries are addressed to it.
If the server does not launch fast enough, the test queries may be run too soon and fail.

Some command flags, such as --server and --auth, are expected to be always the same in successive tests of an API.

To avoid having to repeat these flags for each command, it would be useful to be able to configure them once and for all.

Moreover, it should be possible to keep authentication information secret.

Without proper query and body validation, error messages are sometimes obscure when the test subsequently fails.

Related: #22