Define http api for round trip testing

[tkurki]

To enable round trip testing the test client should be able to send data in different formats and assert that it receives them back in proper format.

Specifically the client should be able to send to the server

• Signal K delta
• nmea0183
• n2k messages as they were coming from producers.

This "test mode" for the server must be separate and invoked explicitly as not to allow sending arbitrary data to the server.

[tkurki]

First suggestion:

• /signalk/v1/api/_test/delta - POST json
• /signalk/v1/api/_test/nmea0183- POST single or multiple line-oriented NMEA0183 sentences
• /signalk/v1/api/_test/n2k - POST single or multiple N2K line-oriented N2K messages

[rob42]

Are you proposing a simple POST>>RESPONSE 'echo' type of functionality? eg no subs or other server processing, just straight through receive>convert>return? Would that prove the server was valid, or just the _test mode? To be reliable I think it might have to work against the actual server in normal operating mode?

[rob42]

Id suggest a test which POSTS an 0183 message, and GETS the expected output keys. It could iterate through a list of some sort to test a range of sentences, Same for N2K and signalk.

Maybe drive it with a json list { "post": "$GPRMC...", "get":{ "navigation.position.value":173.14, etc}}

[rob42]

Actually a json list would also separate the test client from the tests, allowing test clients to be developed in different languages, eg it would be nice to run it as a jUnit test in a normal build.

[tkurki]

What I meant was a way to send data to the server and the server would handle that data exactly as if it were coming from regular providers. This way the data would be sent out via ws and added to the full tree.

The test client could assert whatever it wants: that the proper data matching its subscriptions was sent to it, that multiple values are handled correctly (this one I have working).

So you would start the normal server in some kind of allowTestInput mode and then run the test client sequence against it.

To me encoding the test cases in json and then writing test runners in multiple languages introduces one more way to introduce bugs/different interpretations. I'm have a JavaScript bias, but I still think that writing the tests with the SK js client makes sense. Running the test client isn't overly complicated and actually it could be packaged as an HTML5 application allowing you to run it by opening a web page and pointing it at a server, not unlike InstrumentPanel.

[rob42]

OK I see what you mean now.

In the java server anything you POST is placed in the input queue and processed the same way. So 0183 messages coming from a serial line are pre-processed to decorate them with info like source bus, etc, then pushed onto the input queue.

I guess what the test client needs in /signalk/v1/api/_test/nmea0183 is to do that same message decorating that would normally be done by the serial line reader so the server thinks its come in from the serial line?

[tkurki]

Exactly. And the same for delta & n2k.