Historically there were a lot of lines in test files that were the moral equivalent of:
; Test the `=` operator
(1 = 1)
(2 = 2)
(3 = 3)
...97 lines later...
(100 = 100)
I'm really not exaggerating much. Someone really did like filling up pages with tests like this.
(There's an argument which can be made that if you're testing some basic facilities you might want to start with something more like that, because you haven't established trust in the higher-level language facilities well enough to know that they're working to generate the tests. :-/)
I myself don't like seeing pages of tests like that, so I'd just make a single test that would iterate and fail if anything went wrong:
(count-up index 100 [
do compose [(index) = (index)]
]
true)
But that's kind of lame. The test log just gives you output of "succeeded" or "error". You don't get a view of which iteration was bad on an error, and you don't get a view of the tests that ran successfully.
Meet @COLLECT-TESTS
In your test file, you can now say:
@collect-tests [
count-up index 100 [
keep-test compose [(index) = (index)]
]
]
Then the log would show all the tests that were generated, and if 5 of them succeed but 95 don't you'll see the source and the error for all of them.
This notation isn't necessarily final, but I just picked it to jump off the page a little bit.