sidecars/listener/test/README

   1
   2 Test things for listener. These are broken out to prevent sonar from
   3 analysing them as they force things like passing nil pointers which sonar
   4 finds distasteful and complains (incorrectly) about.
   5
   6 The run_unit_test script will drive the vetting and coverage tests on all
   7 of the library modules in ../src. Coverage files are moved to the parent
   8 directory where the jjb jobs expect to find them.
   9
  10 The run_app_test script drives the listener application and tools, as well
  11 as the test sender, to generate coverage.  There is little vetting done
  12 here; any problems should be discovered by the verify scripts in ../src
  13 at the time the code is pushed. This is simply a coverage test for sonar.
  14
  15
  16 Verification
  17 The unit and app test scripts pretty much verify sucessful runs. If it is
  18 necessary to see things like whether or not the "failure" of a pipe
  19 reader affects the listener (blocks it), then running the app test with
  20 -v and looking at the listener output will help.  Lines like the following
  21 give clues about this:
  22
  23 1616516620 [STAT] (mcl) mtype=0 total writes=1 total drops=0; during last 1s writes=0 drops=0
  24 1616516620 [STAT] (mcl) mtype=1 total writes=88 total drops=0; during last 1s writes=24 drops=0
  25 1616516620 [STAT] (mcl) mtype=2 total writes=88 total drops=0; during last 1s writes=24 drops=0
  26 1616516620 [STAT] (mcl) mtype=3 total writes=88 total drops=0; during last 1s writes=24 drops=0
  27 1616516620 [STAT] (mcl) mtype=4 total writes=88 total drops=0; during last 1s writes=24 drops=0
  28 1616516620 [STAT] (mcl) mtype=5 total writes=88 total drops=0; during last 1s writes=24 drops=0
  29 1616516620 [STAT] (mcl) mtype=6 total writes=10 total drops=78; during last 1s writes=0 drops=25
  30 1616516620 [STAT] (mcl) mtype=7 total writes=0 total drops=88; during last 1s writes=0 drops=25
  31 1616516620 [STAT] (mcl) mtype=8 total writes=0 total drops=88; during last 1s writes=0 drops=25
  32
  33 The sender sends message types 0-8 inclusive, but there are only 7 listeners
  34 started (0-6) so we should never see successful wirte counts for types 7 and 8.
  35 Further, pipe reader for mt 6 stops early, and so we should see some drops after
  36 it has stopped; It stops after 10 successful reads, so the number of writes
  37 should be 10 or 11 depending on timing of the processes. There shouldn't be
  38 any drops on the other FIFOs.
  39
  40 It is difficult, if not impossible, to test the logic that detects an
  41 interrupted write on the pipe to ensure that all data is written.