home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.31 / text0016.txt < prev    next >
Encoding:
Text File  |  1993-07-15  |  2.3 KB  |  45 lines
  1. Submitted-by: emery@goldfinger.mitre.org (David Emery)
  2.  
  3. An issue that many people forget is that there is no such thing as a
  4. test suite against a (language-independent) interface.  All test
  5. suites are written in a programming language, and therefore test the
  6. programming language binding (C, FORTRAN, Ada, Esperanto, whatever.)  
  7.  
  8. If you have language-independent interface specifications, then test
  9. assertions against that LI specification might make sense.  If you are
  10. testing a language binding, then I see no reason for worrying about
  11. test assertions.  Instead, write the actual test, in the programming
  12. language.  This avoids the issue of whether a test suite correctly
  13. implements the assertion.  In the case of the current POSIX.1
  14. standard, we have test assertions against a C language binding.  I
  15. don't find this very useful.  
  16.  
  17. The Ada compiler tests (Ada Compiler Validation Facility) are freely
  18. available.  They are used by implementors to test/debug their
  19. compilers, by (suspicious) users to make sure that the compiler meets
  20. the test, and by the Ada validation facilities (worldwide) to validate
  21. Ada compilers against the DoD validation criteria.  They are
  22. maintained by the Ada Validation Office, and the number of ACVC tests
  23. has at least doubled since its inception, as new tests are developed
  24. to validate parts of the language, and interactions between language
  25. features, that were not included in previous tests.  Contrast this to
  26. the POSIX approach, where the assertions (of no practical use to
  27. anyone except a test developer) are open, but actual test suites are
  28. proprietary to the test labs.  And, in POSIX, the test assertions have
  29. the same development/modification/interpretation/improvement overhead
  30. as the basic POSIX.1 standard, making it very hard to add new
  31. tests/assertions as we learn more about testing POSIX compliance.
  32.  
  33. Frankly, I think the time and effort would have been better spent
  34. developing actual C test suites for POSIX conformance, rather than
  35. spending all of that time developing test methods that require
  36. translation into C to be of any practical use to anyone besides a test
  37. suite developer.  This might put some test suite developers out
  38. of business, but it would be much more useful for the community as a
  39. whole. 
  40.                 dave
  41.  
  42.  
  43. Volume-Number: Volume 31, Number 17
  44.  
  45.