README.testing

   1 Testing LibTracker::Client
   2
   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.
   8
   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.
  14
  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.
  18
  19 So - here's what the LT::C test interface assumes/expects :
  20
  21 $ENV{LTC_TRACKER_RUNNING} : if this is defined, LT::C will try connecting to
  22                             the trackerd instance.
  23
  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.
  29
  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'.
  33