Improve tests by removing EVAL and refactoring

[tbrowder]

Improve tests by removing EVAL and refactoring

This commit:

• Removes subroutines used by:

  S26-documentation/12-non-breaking-space.t
  S32-str/space-chars.t

  to a new module:

  packages/Test-Helpers/lib/Test/Misc.pm6

• Changes the EVALed code in test 12-non-breaking-space.t to a normal test

Files affected:

S26-documentation/12-non-breaking-space.t
S32-str/space-chars.t
packages/Test-Helpers/lib/Test/Misc.pm6

[vrurg]

Seems like the branches diverged. Could you please try rebasing onto the current roast_657?

[tbrowder]

Seems like the branches diverged. Could you please try rebasing onto the current roast_657?

Will do.

[vrurg]

I think removal of the pod-generation part is unfortunate. Hard-coding of whitespaces directly into the test code is dangerous because a "malicious" editor could "normalize" some of them. The best solution, to my view, is to use the approach I've shown in #657 (comment) where pod code is EVALed but then the Pod::Block object is pulled from inside of the EVAL scope.

[vrurg]

With the previous comment in mind, this line would then be replaced with my $r = get-pod; and the rest of the test would remain unchanged. So, we could get the best of two variants: list of chars with codes and names from the initial EVALed version, and easy to work with test code outside of any EVAL.

[tbrowder]

I'll take another look and see what I can come up with.

[vrurg]

The point is not in making it smaller but to have only the pod section evaled. The biggest problem with the initial approach is the difficulty to analyze and modify code spread across several ~= statements.

Simply put, from the original test I'm interested in preserving lines 15 to 79.

[tbrowder]

I can use your example but I can't see how to generate the code internally in the same comp unit without more EVALing. I can generate it fine from another program.

Suggestions? If you know how to do it please show me a short example.

[vrurg]

If I got the misunderstanding correctly, I don't mean to get rid of EVAL altogether. I only want to minimize its use. Thus, EVALing the generated code, the way I eval a piece of pod with a primitive sub in my example, is totally ok.

I mean the separation I'm trying to reach is to make the test code, which is to be read and understood by a human, available directly in one clean piece; and only generate and EVAL the pod block as it is just test input data and barely would be modified or analyzed by a person.

[tbrowder]

Yes, I understand what you want, but I don't see how to do it with a single script. Let me try a new tack and see your reaction. I should get it here later today.

[vrurg]

Let me repeat the example code here:

sub get-pod {
    my $pod;
    my sub pull-pod($p) {
        $pod = $p;
    }
    EVAL q:to/TEST/;
        =begin pod
        Pod text goes here...
        =end pod
        pull-pod($=pod[0]);
        TEST
        
    $pod
}
my $pod = get-pod;
isa-ok $pod, Pod::Block, "fine";

This approximately what I'd like to achieve.

[tbrowder]

I looked again at the situation this morning but I won't start work until you're happy with my proposal below.

First note that I found at least eight test generation programs in roast and that is what I intend to add to the S26 directory. Essentially, I will modify what I did to generate the current test by adding my Raku program and incorporate your excellent method to minimize the EVALed code.

PROPOSAL

• Create two code templates:

  • test-file.raku.top
  • test-file.raku.bottom

• Create the Raku test generator to:

  • write the top part to the test file
  • generate and append the EVALed test code to the test file
  • append the bottom part to the test file (I will add some code to all parts as a check on planned tests such how many table rows are expected and how many were actually found)

• Create a README for the directory to explain the situation

• Put all three non-test parts in a new tools subdirectory

SUMMARY

I believe my approach helps by:

• easing creation and debugging of the main top and bottom of the test file
• clearly show the table generation (the only EVALed code) and characters used
• explaning the approsch for future devs
• declutters the main S26 directory by moving the generation code to a subdirectory

[vrurg]

I don't think two extra files and manipulations with them would greatly improve the test.

I probably failed to explain my idea clearly after all. Please, review 4fffc73 and check if it does what it should. I have grouped the tests into subtests. And added two more tests per row (per subtest). So, now, instead of just outputting the converted lines of ws codes it compares them.

[vrurg]

Apart from me wanting to preserve the pod generation code, things are looking so much better this way! Thank you!

[Altai-man]

Make sure those changes apply well to 6.c-errata and 6.d-errata.
We usually cherry-pick some sane behavior-related changes to spec, but I wonder if massive changes for the sake of code (not spec sanity itself) are necessary.

[vrurg]

@Altai-man the test is not even in spectest.data yet. I don't see a problem here. Otherwise we must think about the manageability of test code because we must remember about those coming into these waters after us.

[vrurg]

I think it makes sense to close this PR after 4fffc73.