Re-enable rcl unit test "test_events" for macOS

[mm318]

The test_events unit test in rcl was flaky when run on the macOS build machine, so it was disabled (intended to be temporarily disabled). This issue to is track re-enabling the test after improving its robustness.

[dirk-thomas]

For reference: 209ec28

[sloretz]

Quick check on OSX testing just rcl @mm318 FYI

[mm318]

The tests passed once (#433 (comment)), got merged, and then failed again (ros2/build_farmer#199).

[jacobperron]

I'm not sure if it's of any consequence, but the reported failure on build cop is part of a release build.

[clalancette]

I'm not sure if it's of any consequence, but the reported failure on build cop is part of a release build.

Yeah, that's almost certainly the case. The release builds (particularly on macOS) expose a lot more bugs than the debug builds.

[mm318]

Are there other unit tests that create a context, node, and publisher/subscriber pair, send a Strings message, and lastly tears everything down, and then repeat a couple of times for the remaining test cases?

Is there some way to run this test with --gtest_shuffle? I've noticed that it's always the last two test cases that fail, with the subscriber failing to receive a published message.

I feel like this test failure is exposing a bigger problem (on macOS) than the test itself.

[jacobperron]

test_communication/test/test_publisher_subscriber launches pub/sub pairs for rclcpp and rclpy with all test messages. But I'm not aware of analogous communication tests strictly in C.

Is there some way to run this test with --gtest_shuffle? I've noticed that it's always the last two test cases that fail, with the subscriber failing to receive a published message

Try setting the env variable GTEST_SHUFFLE=1 (reference).

[nburek]

Are ros2/build_farmer#199 and this tracking the same issue? Should one be closed in preference of the other?

[mm318]

Yeah, let's close this one, as this test is already enabled, which is why it showed up under build_cop.