1 Testing LibTracker::Client
3 So you downloaded LibTracker::Client and you even managed to compile it. But
4 all good modules have tests and so does LT::C. What makes LT::C a little
5 different is that it needs a running trackerd to test stuff. And it would
6 want to change some properties on an entry (path) indexed by tracker to test
7 out most of its functionality.
9 If LT::C were a regular old module, we could get around by using
10 Test::MockObject. But it isn't and we can't. Well, we _can_, but it would be
11 pointless. LT::C is essentially an XS wrapper around libtrackerclient, and
12 we would have to bypass the very XS-ish behaviour that we want to test, if
13 we go via the Test::MockObject route.
15 Another option is to mock the libtrackerclient library and build against
16 that, specifically for testing, but communicating with a real trackerd
17 instance is far easier and more real-world.
19 So - here's what the LT::C test interface assumes/expects :
21 $ENV{LTC_TRACKER_RUNNING} : if this is defined, LT::C will try connecting to
22 the trackerd instance.
24 $ENV{LTC_TEST_PATH} : a path which is indexed by tracker. LT::C will
25 try to make (and revert) changes to this, but
26 naturally - tests might fail. It is good to keep
27 this as a test path. If this is not defined,
28 LT::C will skip all tests which require a path.
30 $ENV{LTC_META_FIELD} : A string type metadata field that the test
31 scripts can play with. If this is not defined,
32 the test scripts assume 'File:Other'.