Skip to content

Add unit testing to robot hardware#109

Merged
bmagyar merged 15 commits intoros-controls:masterfrom
bmagyar:add_unit_testing_to_robot_hardware
Jun 25, 2020
Merged

Add unit testing to robot hardware#109
bmagyar merged 15 commits intoros-controls:masterfrom
bmagyar:add_unit_testing_to_robot_hardware

Conversation

@bmagyar
Copy link
Copy Markdown
Member

@bmagyar bmagyar commented Jun 20, 2020

As per mentioned during the last meeting that this package has no proper unit testing, I've added some for RobotHardware. The initial plan was to move the one from test_robot_hardware but it is very tied to what exactly is happening with that implementation and I wanted to have a more general set of tests.

There are some changes in this PR that should be credited to uncrustify...

On the other hand, @Karsten1987 if you could assist with the cppcheck failure I'd be glad. I am getting the same locally and don't know what to do with it really...

test/test_robot_hardware_interface.cpp:90]: (error: syntaxError) syntax error

@codecov-commenter
Copy link
Copy Markdown

codecov-commenter commented Jun 20, 2020

Codecov Report

Merging #109 into master will increase coverage by 3.11%.
The diff coverage is 50.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #109      +/-   ##
==========================================
+ Coverage   40.98%   44.10%   +3.11%     
==========================================
  Files          24       31       +7     
  Lines         527      653     +126     
  Branches      273      321      +48     
==========================================
+ Hits          216      288      +72     
- Misses         82       83       +1     
- Partials      229      282      +53     
Flag Coverage Δ
#unittests 44.10% <50.00%> (+3.11%) ⬆️
Impacted Files Coverage Δ
...nclude/hardware_interface/joint_command_handle.hpp 100.00% <ø> (ø)
.../include/hardware_interface/joint_state_handle.hpp 100.00% <ø> (ø)
...clude/hardware_interface/operation_mode_handle.hpp 100.00% <ø> (ø)
hardware_interface/test/test_macros.cpp 50.00% <ø> (ø)
hardware_interface/src/robot_hardware.cpp 48.43% <16.66%> (+17.40%) ⬆️
hardware_interface/src/joint_state_handle.cpp 68.18% <50.00%> (-1.82%) ⬇️
...e_interface/test/test_robot_hardware_interface.cpp 50.53% <50.53%> (ø)
hardware_interface/src/joint_command_handle.cpp 70.58% <66.66%> (-0.85%) ⬇️
hardware_interface/src/operation_mode_handle.cpp 71.42% <100.00%> (+4.76%) ⬆️
...face/include/hardware_interface/robot_hardware.hpp 100.00% <0.00%> (ø)
... and 7 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update edae22f...30476af. Read the comment docs.

@jordan-palacios
Copy link
Copy Markdown
Member

jordan-palacios commented Jun 22, 2020

On the other hand, @Karsten1987 if you could assist with the cppcheck failure I'd be glad. I am getting the same locally and don't know what to do with it really...

test/test_robot_hardware_interface.cpp:90]: (error: syntaxError) syntax error

@bmagyar This is the one where it complains on the first usage of TEST_F right? I managed to "fix" it by not having theTEST_F inside a namespace.

Copy link
Copy Markdown
Member

@jordan-palacios jordan-palacios left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Minor changes suggested.

Copy link
Copy Markdown
Contributor

@Karsten1987 Karsten1987 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you please revert the style changes to make the diff smaller here? There's quite a bunch of unrelated and unnecessary whitespace changes in here.

Comment on lines -26 to -30
: name_(),
pos_(nullptr),
vel_(nullptr),
eff_(nullptr)
{}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why these changes? They seem unrelated

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really don't know, as I put in the opening post,

There are some changes in this PR that should be credited to uncrustify...

Sure, I'll revert 'em

Comment on lines -26 to -28
: name_(),
cmd_(nullptr)
{}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why these changes? They seem unrelated

@bmagyar
Copy link
Copy Markdown
Member Author

bmagyar commented Jun 25, 2020

@Karsten1987 all unsolicited style changes have been reverted but I have to admit I kinda like them better that way, may submit a PR later with just that. One outstanding point from you regarding the de-referencing comment.

@jordan-palacios thanks for the note on TEST_F, that fixed it!

Copy link
Copy Markdown
Contributor

@Karsten1987 Karsten1987 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a comment for the name of the validation function, but generally looks good to me.

set_cmd(double cmd);

HARDWARE_INTERFACE_PUBLIC
bool valid_pointers() const;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that function name should be more precise. valid_pointers doesn't really say anything about what that function does, meaning which pointers are being checked.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, the function states pointers as in multiple pointers, the implementation does however only check a single cmd_.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have the same function implemented in all the other handles and I call this from the template function so they should all be called the same. TBH a proper solution would see inheriting such an interface to really ensure this function existing the same way for all

bmagyar and others added 3 commits June 25, 2020 17:10
Co-authored-by: Karsten Knese <Karsten1987@users.noreply.github.com>
@bmagyar bmagyar merged commit aeee004 into ros-controls:master Jun 25, 2020
@destogl destogl mentioned this pull request Nov 15, 2020
destogl pushed a commit to b-robotized-forks/ros2_control that referenced this pull request Aug 11, 2022
* joint_state_controller using resource manager
* Touch up CI version for ros-action

Co-authored-by: Bence Magyar <bence.magyar.robotics@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants