external/bsd/bind/dist/unit/atf-src/TODO

   1 Things to do                                    Automated Testing Framework
   2 ===========================================================================
   3
   4
   5 Last revised: November 30th, 2010
   6
   7
   8 This document includes the list of things that need to be done in ATF that
   9 are most requested by the users. This information used to be available in
  10 an ad-hoc bug tracker but that proved to be a bad idea. I have collected
  11 all worthy comments in here.
  12
  13 Please note that most work these days is going into Kyua (see
  14 http://code.google.com/p/kyua/). The ideas listed here apply to the
  15 components of ATF that have *not* been migrated to the new codebase yet.
  16 For bug reports or ideas that apply to the components that already have
  17 been migrated, please use the bug tracker in the URL above. Similarly,
  18 whenever a component is migrated, the ideas in this file should be revised
  19 and migrated to the new bug tracker where appropriate.
  20
  21
  22 ---------------------------------------------------------------------------
  23 Add build-time checks to atf-sh
  24
  25 The 0.7 release introduced build-time tests to atf-c and atf-c++, but not
  26 to atf-sh. Expose the functionality to the shell interface.
  27
  28 This will probably require writing an atf-build utility that exposes the C
  29 code and can be called from the shell.
  30
  31 ---------------------------------------------------------------------------
  32 Revisit what to do when an Atffile lists a non-existent file
  33
  34 ---------------------------------------------------------------------------
  35 Add ATF_CHECK* versions to atf-c++ to support non-fatal tests
  36
  37 ---------------------------------------------------------------------------
  38 Implement race-condition tests
  39
  40 gcooper:
  41
  42 I would think that stress/negative tests would be of more value than race
  43 condition tests (they're similar, but not exactly the same in my mind).
  44
  45 In particular,
  46
  47 1. Feed through as much data as possible to determine where reporting
  48    breaks down.
  49 2. Feed through data quickly and terminate ASAP. The data should be
  50    captured. Terminate child applications with unexpected exit codes and
  51    signals (in particular, SIGCHLD, SIGPIPE, exit codes that terminate,
  52    etc).
  53 3. Open up a file descriptor in the test application, don't close the file
  54    descriptor.
  55 4. fork(2) a process; don't wait(2) for the application to complete.
  56
  57 There are other scenarios that could be exercised, but these are the ones
  58 I could think of off the topic of my head.
  59
  60 --
  61
  62 jmmv:
  63
  64 1. The thing is: how do you express any of this in a portable/abstract
  65    interface? How do you express that a test case "receives data"? What
  66    does that exactly mean? I don't think the framework should care about
  67    this: each test should be free to decide where its data is and how to
  68    deal with it.
  69
  70 2. Ditto.
  71
  72 3. Not sure I understand your request, but testing for "unexpected exit
  73    codes" is already supported. See wiki:DesignXFail for the feature
  74    design details.
  75
  76 4. What's the problem with this case? The test case exits right away after
  77    terminating the execution of its body; any open file descriptors,
  78    leaked memory, etc. die with it.
  79
  80 5. forking and not waiting for a subprocess was a problem already
  81    addressed.
  82
  83 I kinda have an idea of what Antti means with "race condition tests", but
  84 every time I have tried to describe my understanding of matters I seem to
  85 be wrong. Would be nice to have a clear description of what this involves;
  86 in particular, what are the expectations from the framework and how should
  87 the feature be exposed.
  88
  89 As of now, what I understand by "race condition test" is: a test case that
  90 exercises a race condition. The test case may finish without triggering
  91 the race, in which case it just exists with a successful status.
  92 Otherwise, if the race triggers, the test case gets stuck and times out.
  93 The result should be reported as an "expected failure" different from
  94 timeout.
  95
  96 --
  97
  98 pooka:
  99
 100 Yup. Plus some atf-wide mechanism for the operator to supply some kind of
 101 guideline if the test should try to trigger the race for a second or for
 102 an hour.
 103
 104 --
 105
 106 jmmv:
 107
 108 Alright. While mocking up some code for this, I think that your two
 109 requests are complementary.
 110
 111 On the one hand, when you are talking about a "race condition" test you
 112 really mean an "expected race condition" test. Correct? If so, we need to
 113 extend the xfail mechanism to add one more case, which is to report any
 114 failures as a race condition error and, if there is no failure, report the
 115 test as successful.
 116
 117 On the other hand, the atf-wide mechanism to support how long the test
 118 should run for can be thought as a "stress test" mechanism. I.e. run this
 119 test for X time / iterations and report its results regularly without
 120 involving xfail at all.
 121
 122 So, with this in mind:
 123
 124 * For a test that triggers an unfixed race condition, you set xfail to
 125   race mode and define the test as a stress test. Any failures are
 126   reported as expected failures.
 127
 128 * For a test that verifies a supposedly-fixed race condition, you do *not*
 129   set xfail to race mode, and only set the test to stress test. Any
 130   failures are reported as real failures.
 131
 132 These stress test cases implement a single iteration of the test and
 133 atf-run is in charge of running the test several times, stopping on the
 134 first failure.
 135
 136 Does that make sense?
 137
 138 ---------------------------------------------------------------------------
 139 Implement ATF_REQUIRE_ERRNO
 140
 141 pooka:
 142
 143 Most of the lines in tests against system functionality are:
 144
 145 if (syscall(args) == -1)
 146     atf_tc_fail_errno("flop")
 147
 148 Some shorthand would be helpful, like ATF_REQUIRE_ERRNO(syscall(args))
 149 Also, a variant which allows arbitrary return value checks (e.g. "!= 0" or
 150 "< 124" or "!= size") would be nice.
 151
 152 --
 153
 154 gcooper:
 155
 156 There's a problem with this request; not all functions fail in the same
 157 way ... in particular compare the pthread family of functions (which
 158 return errno) vs many native syscalls. Furthermore, compare some
 159 fcntl-like syscalls vs other syscalls. One size fits all solutions may not
 160 be a wise idea in this case, so I think that the problem statement needs
 161 to be better defined, because the above request is too loose.
 162
 163 FWIW, there's also a TEST macro in LTP, which tests for non-zero status,
 164 and sets an appropriate set of global variables for errnos and return
 165 codes, respectively. It was a good idea, but has been mostly abandoned
 166 because it's too difficult to define a success and failure in a universal
 167 manner, so I think that we need to be careful with what's implemented in
 168 ATF to not repeat the mistakes that others have made.
 169
 170 --
 171
 172 jmmv:
 173
 174 I think you've got a good point.
 175
 176 This was mostly intended to simplify the handling of the stupid errno
 177 global variable. I think this is valuable to have, but maybe the
 178 macro/function name should be different because _ERRNO can be confusing.
 179 Probably something like an ATF_CHECK_LIBC / ATF_CHECK_PTHREAD approach
 180 would be more flexible and simple.
 181
 182
 183 ===========================================================================
 184 vim: filetype=text:textwidth=75:expandtab:shiftwidth=2:softtabstop=2