[rostest] Add reusable node to test parameters.#859
[rostest] Add reusable node to test parameters.#859130s wants to merge 3 commits intoros:indigo-develfrom
Conversation
|
Depending on how it is supposed to be used would it make sense to optionally also check if the parameter has a specific value? |
|
I can cherry-pick this patch manually but please make future PRs against the latest branch, currently kinetic-devel for this repo. |
| # POSSIBILITY OF SUCH DAMAGE. | ||
|
|
||
| # Original copied from hztest node | ||
| # https://github.com/ros/ros_comm/blob/24e45419bdd4b0d588321e3b376650c7a51bf11c/tools/rostest/nodes/hztest |
There was a problem hiding this comment.
If the code was copied it should preserve the original copyright.
There was a problem hiding this comment.
The original is Willow 2008, but I'll just revert.
|
I added a few commits that include the following changes:
Btw I added the changes without squashing but once it LGT I can rebase (or please rely on github's feature).
Sure. I'm still mostly on indigo but changes like this can be easily tested on cloud. |
|
The patch currently fails on test. |
|
Btw where does buildfarm obtain the email that it sends out the build result to? It's using my old one (130s@lateeye.net) that I stopped using awhile ago. |
|
Some tests are still failing. I assume Jenkins has fetched the email address of your user earlier and has cached that value since then. I think you should be able to update your profile yourself: http://build.ros.org/user/130s/configure If not please let me know what I should update the email address to. |
|
Tests passed. And thanks, I was able to resume getting notifications from buildfarm. |
|
Thanks for iterating on this. I have squashed and cherry-picked the change to the |
|
Thank you for the review and acceptance. Do new functionality only go to the newest branch for |
|
Any change should go into the latest development branch. From there certain changes can be backported. After they have been available in the latest distribution for a while and increased the confidence that they don't cause regressions. But backports should happen only when there is a "good reason" to do so (e.g. fix a significant bug). Not every feature should be backported. The reasons not to do it are extra effort and chance of regressions. While I do understand that it would be nice to always have every change all distros the reason why we have distros is to keep already released distros as stable as possible and add new stuff only into new distros. So each request to backport specific changes needs to be considered carefully. |
Adding a node
paramtest, a reusablerostestnode that checks if a designated parameter is registered and non-empty.Inspired by:
hztest, and the implementation and the usage is similar to hztest.Motivation: It's cumbersome to write your own test node when you simply want to check if a parameter is registered and/or is not null.
Usage: Hopefully the usage is obvious enough from a test file that's also added in this PR.