Feature: Common Unit Test Library

[guilyx]

Purpose

Tired of rewriting code, would probably make it easier on everyone to have something like this ?
Not sure if I'm going in the right direction but it seems to be a nice start for testing ROS2 packages.

Approach

Basically created 4 helper classes:

• Basic Subscriber
• Basic Publisher
• Service Client
• Action Client

They're all minimal and the purpose is just to test whatever we use them for.

Ex:

• I create a node that publishes stuff and I want to test it. I just use that common subscriber class and bind it with the right topic name, message type, and I test if the messages received are the one I am sending
• ... same for the others

Open Questions and Pre-Merge TODOs

• Fix reference errors
• Ask @jcmonteiro and @cmraaron if it looks nice
• Implement feedback callback for action client
• Add License
• Add Readme
• Tests for Action Clients
• Tests for Service Clients

Dependencies

None

Disclaimers

• This project should grow from a steady base, if you guys have implementation advice please tell me now so that I don't dive too deep into something that doesn't feel right for everyone 🗡️
• I still don't know if it makes sense to have Action and Service Servers classes for tests ? EDIT: it does
• It should probably have Lifecycle Publisher / Subscriber / Services / Actions in there somewhere, but not now.
• I don't know how this happened tbh, I was writing unit tests for other things and basically copy pasting other unit tests from last week, it triggered me, and now it's midnight on a Saturday 🤪.

Learning

• Template Classes are painful, but.. I like it ?
• When creating a Basic****Test object and spinning it, rclcpp needs some time before calling shutdown - which is why there's an ugly sleep after all spins. (wondering if I should put the sleep in the spin_thread method?)

Blog Posts

• Basic Template Class Course
• Why Template can only be implemented in header files
• CMake Target base system
• Header only ROS2 Packages
  • Helped with setting up the build system alongside with @cmraaron's pointers.
• Race Condition when shutting down rclcpp contexts
  • Points that we should use spin_some in a tight loop and check rclcpp::ok() instead of using spin(). It indeed solved the context error/race condition when we spin then shutdown rclcpp straight away.
• Apparently best practice way of doing setters and getters
  • BUT we don't want to pass references to objects shared across threads.
• Why do we use the typename keyword in some places
• A random reddit about why so many people hate C++

[cmraaron]

I'd be interested to see dogfooding of these to see how much complexity they removed from any tests where we'd have to do something similar

[guilyx]

There's something I'm unsure about here, I'll test this later.

[SomaGallai]

Really cool, could you please a README file just for what is the purpose of the repo and how to properly use it even though it is pretty straight forward.

[guilyx]

Okay, I'm satisfied now with where this is at.

We have wrappers for basic subscribers, publishers, action/service client/server and all of them are tested in the package. I have implemented some of this already in footprint_updater_server and the integration was fairly easy and really simplifying things.

[cmraaron]

thanks for you patience!