Closed lucasw closed 8 years ago
Thanks for the contribution!
Note to self: after this is merged, convert the package.xml
to format 2, and convert the <build_depend>
for camera_info_manger
to a <test_depend>
, making the corresponding CMakeLists.txt
changes.
I wonder if this is safe to release in Indigo?
We need a test to ensure that existing old-format YAML files still work. I don't want to break anyone's currently-working system.
There ought to be a C++ to python test, python to C++ test, and python to python test (already exists?), and save an old format file into the test repository and load it, check values (then save and reload in new format and check values again?).
I have some of the C++ to python started in the last commit, though the cmake isn't hooked up properly- can add_rostest() have a dependency that triggers a cmake custom command? Or another route would be to turn the C++ camera_info generator into a ros node that the python test case can talk to. (Would it make sense for camera_info_manager to have a ros node wrapper for general use?)
There ought to be a C++ to python test, python to C++ test, and python to python test (already exists?), and save an old format file into the test repository and load it, check values (then save and reload in new format and check values again?).
I agree, and though it's not that much work, it's not something I am likely to get to any time soon.
I have some of the C++ to python started in the last commit, though the cmake isn't hooked up properly- can add_rostest() have a dependency that triggers a cmake custom command?
I suppose so. I do want to be careful with the test dependencies, so they don't end up being install dependencies of the actual package.
Or another route would be to turn the C++ camera_info generator into a ros node that the python test case can talk to. (Would it make sense for camera_info_manager to have a ros node wrapper for general use?)
Probably not much general use. The camera_info_manager is really just a small part of a camera driver. But, your generator node could definitely serve as test scaffolding in place of a real camera calibration node. That's a good approach.
I can add the tests.
The cmake camera_info file generation route doesn't work for calling rostest from the command line, so the generator node is now in the .test file and the python calls the C++ service to save the camera info to disk, then reloads and compares. (and add_rostest DEPENDENCIES didn't seem to trigger a cmake add_custom_command)
The next one will be the python to C++ test.
That looks great. Much appreciated!
For #7
My C++ camera info generator could be made into an actual test, right now it is a matter of running that manually, and running the python equivalent manually.