[ros-users] [Discourse.ros.org] [Quality Assurance] Input validation as a metric for quality

[tyagikunal]

I would be using Contracts to mean something to validate input/output against. 
[quote="fkromer, post:6, topic:3732"]
It depends on the overall application context
[/quote]
I completely agree with this. It's upto the user to choose the correct contract. Contracts can't be one-size-fits-all. Moreover, there is little reason not to parametrise the contracts. User might want to choose a lower and upper bound on acceleration along x-axis and y-axis and a total acceleration magnitude constraint. We can't know it in advance. However, we can know that for sensor_msgs/NavSatFix.position_covariance_type, there are only a fixed range allowed, and this can be an example of standard contract. User might include a run time check (only option if the node is in say, python) or a compile time check. We shouldn't limit the options either way. Providing contracts only to a certain language would change the capabilities of ROS as well as the results people expect in different languages.

I think contracts would be like messages. ROS would provide a few standard contracts, but users would be free to combine a standard contract provided by ROS as they wish or write their own to suit their needs. Just like how users might use the Imu message or want to create a new Imu message without orientation or a new message with pressure.

[quote="fkromer, post:7, topic:3732"]
built-in support implement this with conditional injection of the DbC logic during compile time
[/quote]
I've seen people use modified asserts and logging methods which activate based on the compile type (Debug, Release, ReleaseWithDebugInfo). There's no reason why it shoudn't be similar for contracts. This is what makes me skeptical of the contract proposal for C++.

The user should be able to use the contract how ever required. It could be compile time or run time.
Compile time would require using extra libraries or creating new macros or wait for future standard support. But this approach isn't language agnostic. For run time support, leveraging DDS might be a good option.

[quote="fkromer, post:7, topic:3732"]
C++17 supports DbC as well
[/quote]
On a related note, [C++17 standard](https://github.com/cplusplus/draft/tree/c++17) doesn't have contracts.

[quote="fkromer, post:6, topic:3732"]
In many cases the interface data types are too complex to define what valid data is
[/quote]
This is the issue with not only many sensor_msgs (among other messages from visualization_msgs, etc.), but also configuration parameters and dynparams for nodes. This doesn't mean we can't do something for the simpler messages or simpler checks. 

We can add simple contracts, specially the conditions ones written as comments in the messages (number of points is width*height. It's a straight path to segmentation fault in Python as well as C++ without this simple check). In fact, the initial contracts would be simply whatever checks people already use.

I personally feel contracts shouldn't rely solely on compile time DbC because it restricts people from using a language the rest of the logic would be best written in.

Sidenote: Any form of implemented contracts would need to be integrated with `rostopic pub` command line interface or with the message type itself. Or else the user might face trouble diagnosing the reason the messages (from command line) aren't doing what they are supposed to do, and hunting down contracts in every subscribing node might be a headache. If contracts are good, but tooling doesn't exist, people wouldn't use them. If they are bad (the interest in DbC would like to say otherwise :) ), they might as well not exist in the library.





---
[Visit Topic](https://discourse.ros.org/t/input-validation-as-a-metric-for-quality/3732/10) or reply to this email to respond.