Tests missing from spectest.data: worth adding them? #657
Comments
|
Ok, will check |
|
If I understood this correctly, all the S26 tests are passing, right? We
should add them, why not.
|
|
@JJ Can you confirm that the tests themselves are correct? |
|
Ok, considering the "thumb up" as the confirmation. :) Thank you! |
|
Just as a note. I have updated the tool to do different backends. The following table is for both Now I won't need to re-run it every time when terminal output is lost for whatever reason. |
|
@tbrowder ping, please! I have a request to you. |
|
@vrurg it actually meant I was going to do it. Doing it now. Most were added by @tbrowder , BTW.
|
|
@JJ As you can see, I have already found the author. :) I would consider merging 11 and 12 then. Besides, I wanted to ask @tbrowder if it's possible to use less But more direct problem with it is that if anything would ever require fudging then we're in trouble. I understand that the problem is about sub do-test($pod) {
isa-ok $pod, Pod::Block, "is a pod block";
}
EVAL q:to/TEST/;
=begin pod
=end pod
do-test($=pod[0]);
TESTSo, we only incapsulate our data inside the |
|
Update to the example from my last comment: sub get-pod {
my $pod;
my sub pull-pod($p) {
$pod = $p;
}
EVAL q:to/TEST/;
=begin pod
=end pod
pull-pod($=pod[0]);
TEST
$pod
}
my $pod = get-pod;
isa-ok $pod, Pod::Block, "fine";
|
|
I will take the advice from you both and create a PR to put the corrected tests in spectest.data.
As I recall, the test was added during discussions about pod and the non-breaking space problem with the pod renderers. The test investigates the wider range of most, if not all, of the Unicode space chars and lists the ones we use. It tests the round-trip handling and shows the normalizing effect on some of the chars. I have no major problem with the test being moved but I certainly wouldn't dump it. I do think it should stay in the Spec. |
|
@tbrowder That's exactly why am I asking you to rewrite it. Because whereas it can catch a bug now but it makes it extremely hard to diagnose and debug the bug using test code because of everything is |
|
@patrickbkr Is |
|
@vrurg Yes, those tests are good to go. |
|
The table as it looks now: Of those:
The rest requires filtering through problem-solving as I have doubts about the syntaxes or the semantics they're proposing. |
|
@lizmat if you have time to look at |
After a recent fix for Rakudo's
update-passing-test-data.plscript I've done a test run. Here is the output:I wonder if we should consider adding the passing tests to
spectest.data. Even partially passing ones perhaps can be considered worth fudging and adding.Specifically, @JJ – maybe you could say something about
S26-documentationones?Otherwise I'm looking for any possible help with this.
Will be adding more comments as soon as I will proceed through individual tests.
The text was updated successfully, but these errors were encountered: