Description

To help with writing tests conforming to a convention I suggest we add an abstraction layer for use with writing tests.

The concept is instead of printing results without structure (though obvious for humans) we use an abstraction for the results. Not only should this simplify writing tests but also allow easier automation of testing. It allows changing format without changing test logic, for example, a serializer can replace the printf messages to save size.

Here is an example API.

The results of calling the functions would look something like:

# turo_data_int(TH_DEV, 12)
data: 12

# turo_data_bool(TH_DEV, true)
data: True

# turo_data_string(TH_DEV, "foo")
data: "foo"

# turo_data_array(TH_DEV, [1, -1, 256, 0xFFFF, 0xFFFFFFFF], INT32_TYPE, 5);
data: [1,-1,256,65536,-1]

# turo_data_string_object(TH_DEV, "foo", "bar")
data: {"foo": "bar"}

# turo_data_string_object(TH_DEV, "foo", 42)
data: {"foo": 42}

#turo_result_success()
result: Success

#turo_result_error()
result: Error

# turo_result_error_with_code(-ENODEV)
error_code: -12
result: Error

Note, for futureproofing I have a int turo for different contexts.

The format is chosen since it is very readable and easy enough for the firmware to create and for a higher level language to parse (I would rather have the parsing logic on the high level rather than in the firmware).
It is also doesn't require large buffers or states. The data printout is versatile. It is similar to what we have now for some applications. It is very human readable. It also allows debug messages in-between without interfering with the parsing.
I intentionally leave out all the different types of primitives, int32_t` covers many cases and this can get extended as needed.

Here are some questions I would like feedback on:

1. Should this be a different module or combined with the fmt library?
2. How is the naming of the module (test_helpers) and th namespacing?
3. Do I really need to specify each function as print?
4. For the array print should I just have a function for each type or have an enum situation?

Feedback is appreciated!

The long term goal will be to define a testing convention and integrate a riotctrl module and easily automate shell/api based testing.

Useful links

Discussed in #10624