home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / unix / 493 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  2.0 KB
  1. Path: sparky!uunet!not-for-mail
  2. From: karish@pangea.Stanford.EDU (Chuck Karish)
  3. Newsgroups: comp.std.unix
  4. Subject: Test suite problems
  5. Date: 27 Dec 1992 18:21:49 -0800
  6. Organization: Mindcraft, Inc.
  7. Lines: 39
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <1hlobtINN79k@ftp.UU.NET>
  11. References: <1hdn66INNi18@ftp.UU.NET> <1him24INNfct@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: karish@pangea.Stanford.EDU (Chuck Karish)
  16.  
  17. In article <1him24INNfct@ftp.UU.NET> johnl@iecc.cambridge.ma.us
  18. (John R. Levine) writes:
  19. >The problems that people have pointed out with the POSIX tests demonstrate
  20. >that it is not appropriate to standardize test suites, particularly not
  21. >test suites that haven't themselves been tested by a significant amount of
  22. >use.
  23.  
  24. We haven't been discussing standardizing test suites but rather
  25. test methods (lists of assertions).
  26.  
  27. >I'm all in favor of test suites.  I think there should be lots of them,
  28. >since they make the implementor's design so much easier, and raise the
  29. >user's confidence that a product that passed the tests probably works.
  30. >But test suites make poor standards.
  31.  
  32. That's why the current practice is to standardize just the
  33. test methods, largely a specification of the assertions
  34. that a test suite has to test.
  35.  
  36. Once the standards process has determined that the test
  37. methods properly express the base specification, the test
  38. suite implementors have a specification for the tests and
  39. the users of the tests have a way to examine the tests for
  40. correct behavior.
  41.  
  42. This raises the hope that implementors will be able to
  43. produce products that faithfully reflect the base standards,
  44. without ever having to work around test suite bugs.  This
  45. requires, of course, that the certifying authorities, the
  46. test suite implementors, and the standards committees all
  47. be responsive to problem reports.
  48.  
  49. --
  50. Chuck Karish          karish@mindcraft.com
  51. (415) 323-9000 x117   karish@pangea.stanford.edu
  52.  
  53. Volume-Number: Volume 30, Number 3
  54.