Test Unification for Rebol3 and Red
In making suggestions for bounties, @GregP suggested:
> - R2/R3 comparison
> - R3 test cases
The differences between Rebol2 and Rebol3 are largely known in the core, and if you have specific questions StackOverflow is the place to ask...or just make notes and answer your own question. For example, you can read about the Zen Cow:
http://stackoverflow.com/questions/15077974/how-to-use-unicode-codepoints-above-uffff-in-rebol-3-strings-like-in-rebol-2
The GUI changes and the port scheme changes are an area where many became lost. It's rare that foundational design documents were written before implementation was started. *(That's a common practice on these projects, which rubs me the wrong way...I want outlines of behavior for pathological cases before the "easy" cases are tackled in an implementation...as unrewarding as that might seem in the short term.)*
A very useful thing in my view would be to unify the Rebol and Red test cases. The Rebol tests, as they are, are here:
https://github.com/rebolsource/rebol-test/blob/master/core-tests.r
These tests have "evolved" from problems; when a bug is found and a patch made, a test is added for it. Red has many more tests made by Peter Wood, most of which were not motivated by specific bug reports, but a more controlled attempt at achieving coverage:
https://github.com/red/red/tree/master/tests
Both data sets are valuable. There is an impasse of sorts, that Andreas and Ladislav are strong supporters of the way Rebol's test system works, although it is a bit confusing. Rather than declaring a standard for what the "right" answer is (and trying to get the test suite to include platform-specific handling so that you get the "right" output) you look at the test output before your change and after.
Red's tests also include Red/System tests, which do not apply to Rebol.
Trying to make the tests in common would introduce problems of control, however. Again bear in mind that DocKimbel does not want any administrivia that doesn't directly benefit Red to be getting in the way. So breaking out GitHub red/red/tests into some separate project where it could get held up by people bickering over Rebol3 concerns will not be supported.
I think that having one *test system* that both projects agreed upon would be ideal and benefit everyone. If Rebol's test suite had Red's GitHub as a submodule and picked and borrowed from its contents that is the most realistic option in the near term.
Can the parties involved agree? Can Rebol3 pass the Red tests without "uglying" up the Red tests? Will anyone bounty it? I dunno. But there would be payoff from doing this for everyone, I believe.
(Though to keep Ladislav and Andreas happy the common suite would (apparently) need to have a diffing feature vs. the absolute "pass or no pass" logic.)
posted by: Hostile Fork 29-Sep-2014/8:34:13-7:00
I'm all about unification.
posted by: Gregg Irwin 29-Sep-2014/15:05:58-7:00
And I don't care for the REBOL core test format. Never did.
posted by: Gregg Irwin 29-Sep-2014/15:08:41-7:00
I see the biggest issue in unifying tests between Rebol and Red is the difference in philosophical approach.
The Rebol test suite is much more technically sophisticated than the very simple one used by Red. It even handles Rebol crashes and continues to run.
If a test causes Red to crash, the bug is fixed so the test will pass.
I find it difficult to see how this gap can easily by closed.
posted by: Peter Wood 30-Sep-2014/8:59:02-7:00
|