README.verify
上传用户:sy_wanhua
上传日期:2013-07-25
资源大小:3048k
文件大小:5k
源码类别:

流媒体/Mpeg4/MP4

开发平台:

C/C++

  1. From bko@cisco.com Fri Jun 29 19:27:22 2001
  2. Date: Fri, 29 Jun 2001 19:27:10 -0700 (PDT)
  3. From: BRYAN OGAWA <bko@cisco.com>
  4. To: vocal@vovida.org
  5. Subject: Verify.hxx
  6. Hey all,
  7. here is a quick email about how to use Verify.hxx to write test cases.
  8. This information is also in Verify.hxx itself.
  9. Verify.hxx defines several macros which act much like assert() .  The
  10. first, and most important, is
  11. test_verify(test_condition);
  12. where test_condition is a boolean condition (like in assert).
  13. Unlike assert, test_verify does not stop execution.
  14. Use test_verify each time that you want to test something.  
  15. Programs using Verify.hxx should return a value from main().  When you
  16. return, you must return the value of the macro 
  17. test_return_code(number_of_test_cases, number_of_bugs);
  18. number_of_test_cases should be the number of calls to test_verify()
  19. made in your program.  For the moment, you should set number_of_bugs
  20. to 0.
  21. Here is a sample program using test_verify:
  22. Example 1 (VerifyExample01.cxx):
  23. #include "Verify.hxx"
  24. int equals(int a, int b)
  25. {
  26.     return a == b;
  27. }
  28. int main()
  29. {
  30.     test_verify(0 == 0);
  31.     test_verify(1 == 1);
  32.     test_verify(1 != 0);
  33.     test_verify(equals(0, 0));
  34.     test_verify(equals(1, 1));
  35.     test_verify(!equals(0, 1));
  36.     return test_return_code(6);
  37. }
  38. End Example 1
  39. the output of this program:
  40. VerifySummary:VerifyExample01.cxx:6:6:0:0:0
  41. ----------------------------------------------------------------------
  42. Report for VerifyExample01.cxx
  43. Summary: PASS
  44. Total Number of Test Cases: 6
  45. Number of Test Cases run: 6
  46. test_verify()
  47.     Expected:   6
  48.     Passes:     6
  49.     Fails:      0
  50. test_bug()
  51.     Expected:   0
  52.     Bugs:       0
  53.     Fixed Bugs: 0
  54. ======================================================================
  55. The reason for the value of the number of test_verify()s being passed
  56. to test_return_code is s that test_return_code() can insure that all
  57. of the calls to test_verify() were made correctly.  If we set it to a
  58. wrong value, this will be reflected in the error logging from the
  59. program.
  60. Example 2 (VerifyExample02.cxx):
  61. #include "Verify.hxx"
  62. int equals(int a, int b)
  63. {
  64.     return a == b;
  65. }
  66. int main()
  67. {
  68.     test_verify(0 == 0);
  69.     test_verify(1 == 1);
  70.     test_verify(1 != 0);
  71.     test_verify(equals(0, 0));
  72.     test_verify(equals(1, 1));
  73.     test_verify(!equals(0, 1));
  74.     return test_return_code(5); // this is wrong, 5 should be 6
  75. }
  76. End Example 2
  77. Here is the output of example 2:
  78. VerifySummary:VerifyExample02.cxx:5:6:0:0:0
  79. ----------------------------------------------------------------------
  80. Report for VerifyExample02.cxx
  81. Summary: TEST BROKEN
  82. Total Number of Test Cases: 5
  83. Number of Test Cases run: 6
  84. test_verify()
  85.     Expected:   6
  86.     Passes:     6
  87.     Fails:      0
  88. test_bug()
  89.     Expected:   0
  90.     Bugs:       0
  91.     Fixed Bugs: 0
  92. Help With Broken Tests:
  93. The number of test cases and bugs specified in test_return_code() did not
  94. match the number of times test_verify() and/or test_bug() were called.
  95. To fix this, you should probably update the number of times you expect
  96. test_verify() and/or test_bug() to be called in the arguments to
  97. test_return_code().
  98. ======================================================================
  99. You can see that the output of the program indicates that this test
  100. case is broken.
  101. The reason for keeping track of the number of test cases is to make
  102. sure that everything is OK -- that all of the test cases you planned
  103. on running were run.
  104. But what if we had not finished writing the code for equals() , and so
  105. had stubbed it out to always return 0? 
  106. If you have test cases which you know will be broken for a long time,
  107. you can replace test_verify() with test_bug() .  test_bug() still runs
  108. the test, but it does not consider a false result to be a "failure", but
  109. a "known bug". 
  110. Example 3 shows this case:
  111. #include "Verify.hxx"
  112. int equals(int a, int b)
  113. {
  114.     return 0;
  115. }
  116. int main()
  117. {
  118.     test_verify(0 == 0);
  119.     test_verify(1 == 1);
  120.     test_verify(1 != 0);
  121.     test_bug(equals(0, 0));
  122.     test_bug(equals(1, 1));
  123.     test_bug(!equals(0, 1));
  124.     return test_return_code(6);
  125. }
  126. Here's the output:
  127. VerifyExample03.cxx:16: test case '!equals(0, 1)' unexpected pass (passed when fail expected)
  128. VerifySummary:VerifyExample03.cxx:6:3:0:2:1
  129. ----------------------------------------------------------------------
  130. Report for VerifyExample03.cxx
  131. Summary: PASS WITH KNOWN BUGS
  132. Total Number of Test Cases: 6
  133. Number of Test Cases run: 6
  134. test_verify()
  135.     Expected:   3
  136.     Passes:     3
  137.     Fails:      0
  138. test_bug()
  139.     Expected:   3
  140.     Bugs:       2
  141.     Fixed Bugs: 1
  142. ======================================================================
  143. You'll notice that the line 
  144. VerifyExample03.cxx:16: test case '!equals(0, 1)' unexpected pass (passed when fail expected)
  145. appears.  This indicates that a test_bug() returned true, meaning that
  146. the test case might have been fixed.  It reports the line number to
  147. make debugging easier.
  148. The code for Verify.hxx is in the util directory, and is working now
  149. on HEAD.  The example code above is in util/test .
  150. If you can isolate test cases down to a minimum failure case, and use
  151. Verify.hxx as the test driver, it will be much easier for us to
  152. integrate these tests into an automated framework (coming soon!) to
  153. help simplify testing for everyone.
  154. Questions and comments are welcome.
  155. -- 
  156. Bryan K. Ogawa  <bko@cisco.com>  http://www.vovida.org/