home *** CD-ROM | disk | FTP | other *** search
/ Geek Gadgets 1 / ADE-1.bin / ade-dist / cvs-1.8.7-src.tgz / tar.out / fsf / cvs / TESTS < prev    next >
Text File  |  1996-09-28  |  5KB  |  129 lines
  1. To run the tests:
  2.  
  3.     $ make check
  4.  
  5. Note that if your /bin/sh doesn't support shell functions, you'll
  6. have to try something like this, where "/bin/sh5" is replaced by the
  7. pathname of a shell which handles normal shell functions:
  8.  
  9.     $ make SHELL=/bin/sh5 check
  10.  
  11. WARNING:  This test can take quite a while to run, esp. if your
  12. disks are slow or over-loaded.
  13.  
  14. You will probably need GNU expr, which is part of the GNU sh-utils
  15. package.
  16.  
  17. If there is some unexpected output, that is a failure which can be
  18. somewhat hard to track down.  Finding out which test is producing the
  19. output is not always easy.  The newer tests (that is, ones using
  20. dotest*) will not have this problem, but there are many old tests
  21. which have not been converted.
  22.  
  23. If running the tests produces the output "FAIL:" followed by the name
  24. of the test that failed, then the details on the failure are in the
  25. file check.log.  If it says "exit status is " followed by a number,
  26. then the exit status of the command under test was not what the test
  27. expected.  If it says "** expected:" followed by a regular expression
  28. followed by "** got:" followed by some text, then the regular
  29. expression is the output which the test expected, and the text is the
  30. output which the command under test actually produced.  In some cases
  31. you'll have to look closely to see how they differ.
  32.  
  33. If output from "make remotecheck" is out of order compared to what is
  34. expected (for example,
  35.  
  36.    a
  37.    b
  38.    cvs foo: this is a demo
  39.  
  40. is expected and
  41.  
  42.    a
  43.    cvs foo: this is a demo
  44.    b
  45.  
  46. is output), this is probably a well-known bug in the CVS server
  47. (search for "out-of-order" in src/server.c for a comment explaining
  48. the cause).  It is a real pain in running the testsuite, but if you
  49. are lucky and/or your machine is fast and/or lightly loaded, you won't
  50. run into it.  Running the tests again might succeed if the first run
  51. failed in this manner.
  52.  
  53. For more information on what goes in check.log, and how the tests are
  54. run in general, you'll have to read sanity.sh.  Depending on just what
  55. you are looking for, and how familiar you are with the Bourne shell
  56. and regular expressions, it will range from relatively straightforward
  57. to obscure.
  58.  
  59. If you choose to submit a bug report based on tests failing, be
  60. aware that, as with all bug reports, you may or may not get a
  61. response, and your odds might be better if you include enough
  62. information to reproduce the bug, an analysis of what is going
  63. wrong (if you have the time to provide one), etc.  The check.log
  64. file is the first place to look.
  65.  
  66. ABOUT STDOUT AND STDERR
  67. ***********************
  68.  
  69. The sanity.sh test framework combines stdout and stderr and for tests
  70. to pass requires that output appear in the given order.  Some people
  71. suggest that ordering between stdout and stderr should not be
  72. required, or to put it another way, that the out-of-order bug referred
  73. to above, and similar behaviors, should be considered features, or at
  74. least tolerable.  The reasoning behind the current behavior is that
  75. having the output appear in a certain order is the correct behavior
  76. for users using CVS interactively--that users get confused if the
  77. order is unpredictable.
  78.  
  79. ABOUT TEST FRAMEWORKS
  80. *********************
  81.  
  82. People periodically suggest using dejagnu or some other test
  83. framework.  A quick look at sanity.sh should make it clear that there
  84. are indeed reasons to be dissatisfied with the status quo.  Ideally a
  85. replacement framework would achieve the following:
  86.  
  87. 1.  Widely portable, including to a wide variety of unices, NT, Win95,
  88. OS/2, VMS, probably DOS and Win3, etc.
  89.  
  90. 2.  Nicely match extended regular expressions of unlimited length.
  91.  
  92. 3.  Be freely redistributable, and if possible already the kind of
  93. thing people might have already installed.  The harder it is to get
  94. and install the framework, the less people will run the tests.
  95.  
  96. The various contenders are:
  97.  
  98. * Bourne shell and GNU expr (the status quo).  Falls short on #1
  99. (we've only tried unix and NT, although MKS might help with other DOS
  100. mutants).  #3 is pretty good (the main dependency is GNU expr which is
  101. fairly widely available).
  102.  
  103. * Bourne shell with a new regexp matcher we would distribute with
  104. CVS.  This means maintaining a regexp matcher and the makefiles which
  105. go with it.  Not clearly a win over Bourne shell and GNU expr.
  106.  
  107. * Bourne shell, and use sed to remove variable portions of output, and
  108. thus produce a form that can be compared with cmp or diff (this
  109. sidesteps the need for a full regular expression matcher as mentioned
  110. in #2 above).  The C News tests are said to work this way.  This would
  111. appear to rely on variable portions of output having a certain syntax
  112. and might spuriously recognize them out of context (this issue needs
  113. more investigation; it isn't clear how big a problem it is in
  114. practice).  Same portability issues as the other choices based on the
  115. Bourne shell.
  116.  
  117. * Dejagnu.  This is overkill; most of dejagnu is either unnecessary
  118. (e.g. libraries for communicating with target boards) or undesirable
  119. (e.g. the code which stats every file in sight to find the tests).  On
  120. the plus side, dejagnu is probably closer than any of the other
  121. choices to having everything which is needed already there.
  122.  
  123. * Write our own small framework directly in tcl and distribute with
  124. CVS.  The tests would look much like dejagnu tests, but we'd avoid the
  125. unnecessary baggage.  The only dependency would be on tcl (that is,
  126. wish).
  127.  
  128. * perl or python or <any other serious contenders here?>
  129.