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: