On Mon, Dec 6, 2010 at 10:30 AM, Brian Gerkey <gerkey@willowgarage.com> wrote:
> On Mon, Dec 6, 2010 at 8:12 AM, Jack O'Quin <jack.oquin@gmail.com> wrote:
>> I'm creating some rostest files for camera1394, but most of them
>> require the presence of a real device. I don't want these tests run on
>> the Hudson build farm, because it lacks the requisite cameras.
>>
>> I can define them using `rosbuild_add_rostest_labeled(device
>> tests/camera_hz.test)`, so they will run if $ROS_BUILD_TEST_LABEL is
>> set to `device`. But, they also run if ROS_BUILD_TEST_LABEL is unset.
>
> Yes, that's the intended behavior.  The idea is that 'make test' with
> no environment setup should run all the tests.  That way, developers
> don't have to set ROS_BUILD_TEST_LABEL.
>
>> Can I control how the test label is defined for Hudson builds?
>
> If the build uses hudson_helper (which I think the builds still do),
> it takes a command-line option --test-label <label>, which in turn is
> assigned to ROS_BUILD_TEST_LABEL.  If it's not provided, then
> hudson_helper sets the label to 'hudson'.  That way, tests that have
> special needs, as indicated by being labeled, won't be run.
>
>> Is there a different method recommended for managing these kinds of tests?
>
> No, you're doing the right thing.  If you label your tests, then
> they'll run when you do 'make test', and they won't run in the usual
> Hudson builds.  In some cases, we create special Hudson jobs that use
> --test-label to set a particular label, to run special tests.  E.g.,
> we use the 'gazebo' label on Gazebo-based regression tests that need a
> GPU (and significant CPU resources); those tests run in special jobs
> that are bound to GPU-equipped machines (most of the build farm
> doesn't have graphics hardware).  We could do something similar for
> tests that require peripherals to be attached, like your camera tests.

Thanks, Brian. That sounds great.

As a follow-up, I'd also like to build some integration tests that
demonstrate the camera working with various image pipeline features,
such as rectification and Bayer decoding. But, camera1394 does not
(and should not) have a build dependency on image_pipeline.

The obvious solution is a separate camera integration test stack.

Does one already exist?

  If so, is it OK to add some camera1394 tests to it?

  If not, is it OK to create one? Where in SVN should that go?
-- 
 joq