I'm a ROS user (~7 years) and occasional contributor. One interesting wart you find in the ROS community is that there are two main supported ways of testing yo

I'm a ROS user (~7 years) and occasional contributor. One interesting wart you find in the ROS community is that there are two main supported ways of testing your ROS code: - Unit test the individual functions and classes using gtest or nose (this is built into catkin, this buildsystem). - Integration test your ROS APIs bringing up an actual ROS multi-process system and having a designated test node which exits to deliver the pass/fail verdict (this is managed by the "rostest" package). The much-touted advantage of microservices is supposed to be that you have these obvious service interface boundaries at which to test, but the reality in ROS land is that it's a lot of work to test there. It's work to generate the binaries or playback data, failures are harder to understand, and because you're at the mercy of RPC timing, nothing is deterministic, so your tests end up full of fudge factors and tolerances. And on top of that, the tests themselves execute way slower, since there's so much more set up and teardown. Is that a failure in the framework? Not sure, but the end result of it is that you only test at the RPC boundary that functionality which can only be tested there; everything else is stuffed into library functions that can be verified with gtest.