@firesurfer Thank you for taking time and create a new issue. Once you have the testcase, we can try to find a solution. It would be really nice to have such testcase, so we don't introduce the bug in future

@saikishor good morning. Could you please point me out where the best place is to add such a test?

I found so far:
https://github.com/ros-controls/ros2_control/blob/master/hardware_interface_testing/test/test_components/test_actuator.cpp

Shall I just add an exclusive actuator there ?

@firesurfer Yes you can add it over there. Can you name it as test_actuator_exclusive_interfaces.cpp because you are focusing on the interfaces part

I went through the code roughly, it is more or less good. Now, the part is to reproduce the same failure you have in the perform command switch in the test :)

That should be rather easy. I will add a test controller (prob. here? https://github.com/ros-controls/ros2_control/tree/master/controller_manager/test) that fails during activation and claims some of the interfaces.

Regarding the testing procedure:

1. Setup a system that uses the hardware interface in Exlusive hw interface rolling #1492
2. Load and activate the controller from added a test controller that fails at activation #1493

The hw interface should now be in a state in which it has a "started" command interface that has not been stopped.

3. Try to load and activate the failing controller or another one that uses the command interface.

The hw interface should now deny the prepare_command_mode_switch

@firesurfer add both #1492 and #1483 in the same PR, so you can clearly write a TEST case to reproduce it

@firesurfer
When I meant test, If you can write a test like how the tests are written in the tests folder of the packages, that's why merging both PRs into one would make sense

Sorry for that.
But for someone who is not really involved in the ros2control development adding something, especially adding test looks rather difficult/ time consuming at the moment, as there are quite a lot of infrastructure and internal internal interfaces involved. Additionally I couldn't find any documentation about the test infrastructure and best practices.

I am really willing to provide the test code but I could really use some help setting up the necessary glue/infrastructure code.

I merged both PRs in #1492

@firesurfer Right now we are occupied with the current developments for Jazzy, if we are done with it, I can take a look at this later. I hope this is not a problem 👍

@saikishor Thanks a lot!

@firesurfer In the meantime, you can check how different tests are written. The integration tests are in the hardware_interface_testing package. I usually find a similar test, copy it, and then start changing it. You can add it to any file, and we will easily move it.