Re: Will Martin contribute to XEmacs in the future?

Stephen, I consider your argument here utterly wrong. Please reconsider. mb> I hope you're not suggesting that there be only one set of mb> tests, to be applied to all different versions of the SJT> Of course I am. mb> software. The point of a test suite is to reflect what works mb> in any particular version. SJT> Well, why not just reduce it to SJT> (message "All tests passed.") ?!!!???? SJT> and make absolutely sure that works, then? Because the point of a SJT> test suite is to reflect a _specification_, ie, what _should_ work, of SJT> course! SJT> If "stuff" depends on new features, then condition on them, and emit SJT> "unimplemented" warnings. Don't condition on versions; who knows if a SJT> fix might not be backported? If you must condition on versions, when SJT> "stuff" is known not to work in a particular version and there's no SJT> feature to test, you should either accept the failure or (if it would SJT> impact the system) disable the test and emit a "disabled" warning. If you backport a fix, you can backport the regression test that goes with it. Porting the test is usually much easier. mb> Test suites are the ultimate non-portable software, SJT> Test _scaffolding_ is of course non-portable, since it may depend on SJT> implementation-specific hooks and extensions to instrument behavior. I think precisely the opposite. Disciplined organizations require bug fixes to be accompanied by a test case which fails before the bug fix and succeeds afterwards. SJT> Test _suites_ should be portable to any implementation that purports SJT> to comply with the specification. Implementation-independent test suites are most useful when there is a formal standard with multiple implementations. Even if such tests existed, it does not relieve implementors of the burden of creating their own white-box tests for their own specific implementation, as happens, e.g. with gcc and Sun Java. mb> and rightly so. SJT> Necessary evil, at best.