I like your ideas and think this could be very useful. However, one should keep in mind that writing a complete specification of the expected behavior of a node is as complex as writing the node itself; if you had a complete mapping from input to output, you could just execute it instead of running the node. So writing a full functional mapping of input to output is probably infeasible. In your example, you're doing something else: You specify invariants that should hold (velocity magnitude is clamped, and dv/dt corresponds with accel_max), while leaving open some degrees of freedom in the behavior of the node. I think this is the way to do it.
By the way, are you familiar with [rostest](
http://wiki.ros.org/rostest)? An example where it's used are the [tests for robot_pose_ekf](
https://github.com/ros-planning/navigation/tree/kinetic-devel/robot_pose_ekf/test). Here they just test some simple properties of the node's output topics and check that the final estimated pose is correct. This is probably enough to catch 95% of regression bugs.
---
[Visit Topic](
https://discourse.ros.org/t/feedback-wanted-test-framework-for-verifying-topic-output-both-unit-and-integration-testing/5336/3) or reply to this email to respond.
If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <
http://lists.ros.org/mailman//options/ros-users>