Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Outdent subtest intro comment #396

Merged
merged 1 commit into from

8 participants

@dagolden

This commit puts the subtest intro comment at the parent indent level.

Before:

ok 1 - regular test
    # Subtest: my first subtest
    ok 1 - first test
    ok 2 - second test
    ok 3 - third test
    1..3
ok 2 - my first subtest

After:

ok 1 - regular test
# Subtest: my first subtest
    ok 1 - first test
    ok 2 - second test
    ok 3 - third test
    1..3
ok 2 - my first subtest

I think this is much easier to read because it brackets the subtest
information at the same indentation level. The subtest details are
clearly between the opening comment and the matching "ok".

@dagolden dagolden Outdent subtest intro comment
This commit puts the subtest intro comment at the parent indent level.

Before:

    ok 1 - regular test
        # Subtest: my first subtest
        ok 1 - first test
        ok 2 - second test
        ok 3 - third test
        1..3
    ok 2 - my first subtest

After:

    ok 1 - regular test
    # Subtest: my first subtest
        ok 1 - first test
        ok 2 - second test
        ok 3 - third test
        1..3
    ok 2 - my first subtest

I think this is much easier to read because it brackets the subtest
information at the same indentation level.  The subtest details are
clearly between the opening comment and the matching "ok".
4829c9f
@exodist
Owner

I personally really like this. But I am concerned about the change effecting other things. Does TAP::Parser handle it ok? Do we have to worry about breaking things anywhere with this indentation?

@dagolden

As I understand it, comments are semantically invisible. Adding subtest header comments at any level shouldn't break things any more than adding any note/diag anywhere.

But I'll ask on #perlqa and see what people say.

David

@rjbs
Owner

Should be safe.

@Ovid
@tobyink

IIRC, when Test::More first introduced that introductory comment, it broke the test suites for a few Test::* modules, which were capturing the TAP output of subtests and testing it with regexps.

One particular example that I remember was Test::Moose::More. I believe the Test::Moose::More test suite now uses a TAP parser to test the TAP output, so hopefully will now be resilient to this PR.

I think this PR is worthwhile, but before releasing it as stable, it might make sense to blog about the change, and also explain to the authors of Test::* modules the best ways to test their modules that won't fall foul of this this sort of change in the future.

@exodist
Owner
@dagolden

I don't use blogs.perl.org for various reasons, but I can put together a blog post on dagolden.com and someone who is willing to suffer blogs.perl.org can point people to it.

@exodist
Owner
@dagolden

No problem. I have a Friday work deadline and few tuits until next week anyway.

@exodist exodist merged commit 3e0a6e5 into Test-More:master
@exodist
Owner

Test-Simple-1.001004_001 has been uploaded to pause. Assuming no complaints about it I will release a non-alpha in a week or so.

@dagolden

Thank you very much! I'm looking forward to using this in a stable release.

@exodist
Owner

Some excellent points about this have been made in another thread (I asked those who commented to bring their discussion here). It has me wondering more about releasing this as-is. I will probably release it as is, but before I do I want to mention an idea. I want feedback on the idea, but I will say out-right that I do not think very highly of it:

use Test::More tap => 'new';
use Test::More tap => 'compatible'; # default

tap => 'compatible' will never change except to add entirely new features, or fix real bugs. Changes to existing things, like this request, never apply here.

tap => 'new' will be subject to tuning type changes, and anyone that uses them will need to be aware that testing the output of Test::Builder using this is the wrong approach.

Once again, this idea does not thrill me, but it is a thought to add into the discussion.

Ultimately what we need is a formatter layer between Test::Builder and TAP. Testers should verify against a result stream, not against TAP output. @schwern and I have discussed this, but it is not likely to happen in the near future.

@RsrchBoy
Owner

This is not a safe change, as Test::Builder::Tester will not handle the output changes. If TBT is broken, then any package relying on it may also break. As TBT is, AFAICT, the de jure approach to testing test modules, then this is... problematic.

Especially as Test::Builder::Tester is included in this distribution :)

Instead of calling packages that use Test::Builder::Tester fragile and saying their tests will be broken by this change, perhaps a better approach would be to fault TBT and fix it? Say, by allowing a testing test author to tell TBT to ignore any comments in the output stream? We can't just reasonably say "comments don't mean anything", as sometimes we do want to validate that our test modules provide useful information in their comments (e.g. is_deeply()).

@dagolden

TBT's approach is inherently fragile. That it ships with Test-Simple doesn't change that fact.

TBT doesn't deal with subtests at all, which is a pretty clear indication that it's suffering from bitrot. It was never updated as Test::Builder itself was. I appreciate that @RsrchBoy put a lot of effort into TAP::SimpleOutput to hack around that omission, but that's just piling more fragility on top, because now we have another TAP generator involved in the mix, too.

@RsrchBoy
Owner

TBT doesn't deal with subtests at all, which is a pretty clear indication that it's suffering from bitrot.

Then let's update and fix TBT, not just break it and say "too bad, suckers!" :) If we provide TBT to test our test modules with, then we have an obligation to not just up and break it.

The future is, yes, the future. But we're not there yet, and in the here and now this breaks actual functionality for the sake of readability. Tracking what subtest is currently running in is more than somewhat awkward w/o this PR or a note() at the beginning of the subtest, but I'm having a hard time accepting that we should be breaking other long-standing parts of our infrastructure just for the sake of adding this one comment into the TAP stream.

(...and the stream is the thing, whatever we may think of that, because all our tools are designed around the idea that tests produce TAP and harnesses/etc consume TAP. If we want to move away from that, fine, but that's an entirely different discussion.)

@dagolden

My point is that it was already broken. This change just exposes the fragility -- which is the definition of fragility in this sense.

What you seem to be saying is "don't change anything until TBT isn't fragile" and while I accept that as an ideal, I don't think it's practical.

@RsrchBoy
Owner

There's a difference between broken in concept and broken in execution. I'm not saying "don't change anything until TBT isn't fragile", rather "this breaks actual functionality for the sake of readability ... I'm having a hard time accepting that we should be breaking other long-standing parts of our infrastructure just for the sake of adding this one comment into the TAP stream."

@exodist
Owner

@RsrchBoy I am sorry this breaks your code. I understand how frustrating it can be to have something external break your code. I do not think anyone meant it as a personal insult telling you that the code is fragile. Also I recognize your arguments, and think you make some very important points.

@dagolden I still think this change is worthy, and I want to bring it into a stable release, but I think we need to take a bit more time to make sure projects are prepared.

Ultimately my standpoint is this: The outdented comment is there for humans, not machines. If it is for machines it should not be a comment, but a formal part of TAP. I think this change makes the comment more human readable, and that is important.

However, since the change was predicted to break things, and has been seen breaking things, I do think a longer delay before it goes into prod is warrented.

@RsrchBoy, Sorry to ask this, but would you mind terribly adapting your code to work with the new Test::More, possibly conditioned on version? I know it is not ideal, and may well be a PITA for you. But for the moment assume the debate has ended in favor of the change, what steps are necessary for your code to get past it, how big of a PITA is it for you?

@RsrchBoy
Owner

@exodist yep, I can do that. I'm going to have to think a little bit about it -- I'd rather not end up having to do it again, shortly.

@dagolden -- I do like the change; subtests can be great but not knowing which one you're in is... frustrating. :) I just find myself in the odd position of arguing for (possibly excessive) stability over most things as time goes on.

@exodist
Owner

@rsrchboy, thanks, also I will be at the next pdx.pm meeting next week, we can put out heads together on this if you would like. I also would hate to break things again in the near future.

@schwern and I have talked about an improvement that can aid in this, perhapse you would like to be involved?

@dagolden

@exodist I understand the rationale for delay and see no reason to rush things

@RsrchBoy thanks for understanding and I apologize if you took my comment about "fragile" personally

I'll think about possible ideas for TBT and report back if I get any inspiration.

@tobyink

Test::Tester has a much better approach for testing Test::* modules. I'm not saying everybody should jump ship to Test::Tester, because it has its own problems (it too has problems with subtests), but I think the general approach it uses is correct:

Rather than testing the TAP output stream, parse the TAP into some native Perl structures (hashrefs, arrayrefs, etc), and then use standard Test::More functionality like is_deeply and like to test those.

@dagolden

As I was looking into TBT improvements, I realized that a big part of the "problem" is that subtests aren't TAP -- they're a hack using indentation to avoid having them parsed. If there were a formal way to indicate the start and end of a subtest, we could use an actual TAP parser to parse the results.

@tobyink

There's already a formal end for the subtest: its "ok"/"not ok" line. And sometimes there's a formal start: its plan.

1..2
ok 1 - a test without subtests
    1..2                              <--- here's a formal start
    ok 1 - first subtest
    ok 2 - second subtest
ok 2 - a test with subtests           <--- here's a formal end

What I think we need is an explicit start for tests that have no plan. Something like:

1..2
ok 1 - a test without subtests
    1..?                              <--- here's a formal start
    ok 1 - first subtest
    ok 2 - second subtest
    1..2
ok 2 - a test with subtests           <--- here's a formal end
@tobyink

On second thoughts, 1..? might confuse existing TAP parsers. How about ... instead?

@dagolden
@tobyink

I'm not a big fan of comments that are not really comments, and in the case of TAP it really is not necessary to hijack the comment syntax. The TAP 12 spec (still the most widely implemented) says:

Any output line that is not a version, a plan, a test line, a diagnostic or a bail out is considered an "unknown" line. A TAP parser is required to not consider an unknown line as an error [...] This is to allow for forward compatability.

TAP 13 says:

Any output that is not a version, a plan, a test line, a YAML block, a diagnostic or a bail out is incorrect. How a harness handles the incorrect line is undefined.

In either case, provided that the line doesn't look like a piece of already known TAP syntax, it should be possible to standardise a new TAP syntax feature without breaking backcompat.

@exodist
Owner

I think we should go with something that does not look similar to normal TAP.

ok 1 - foo
    --SUBTEST START--
    ok 1 - bar
    ok 2 - baz
    --SUBTEST END--
ok 2 - the subtest

It is ugly, but it is also not meant for human consumption. In addition it is not a comment. No sane parser would process it unless it explicitly handles sub-tests with this format. We could also use this as a 'standard' when adding things on top of TAP.

Yay/Nay?

@dagolden

Nay. It has the same problem that I have to look to the end to find out what subtest is running.

The outdent comment is visually distinctive to humans and is easy to parse:

ok 1 - regular test
# Subtest: my first subtest
    ok 1 - first test
    ok 2 - second test
    ok 3 - third test
    1..3
ok 2 - my first subtest

The special comment starts the subtest, which proceeds to the next outdented line. Everything in between gets parsed as TAP as normal, just with indentation removed.

@exodist
Owner

I missed that requirement. How about:

ok 1 - foo
    --SUBTEST START: my first subtest--
    ok 1 - bar
    ok 2 - baz
    --SUBTEST END: my first subtest--
ok 2 - my first subtest
@exodist
Owner

Partially related: See the https://github.com/Test-More/test-more/tree/Result_Stream branch I just started. The idea is to put a layer between Builder and TAP. I am not married to the terminology or names of this branch. I would welcome patches, feedback, competing branches, etc. Ultimately though nothing will change until someone kicks it off, I have done that.

I will try to make time to work on this branch as I can, I am currently on a business trip, which actually gives me more time than normal since I am not wrangling kids after work :-).

@dagolden
ok 1 - foo
    --SUBTEST START: my first subtest--
    ok 1 - bar
    ok 2 - baz
    --SUBTEST END: my first subtest--
ok 2 - my first subtest

This has the same problem that originally prompted me to send the outdented comment patch: the subtest looks like it's part of ok 1 - foo, not ok 2 - my first subtest.

When scanning down a lot of subtests, my eye has to jump in and out of the indention to find subtest name before the actual test results.

@dagolden

@exodist can you open a separate issue to discuss the branch, please?

@exodist
Owner

@dagolden done: #401

@dagolden As for the subtest format, I am open to suggestions. What info would you like to see, and where? Also note, my example above does not include the human readable comments, those would remain unchanged. Would it help you if the --SUBTEST START: ...-- lines were moved left 4 spaces?

@magnolia-k
Collaborator

I have tried to write the parser of simple TAP which supports a subtest.
https://github.com/magnolia-k/p5-TAP-Tree

It is not smart to judge whether it is a subtest or not based on the the numbers of indents :)

I think it is good to be a comments format (since the success or failure of the whole subtest are displayed perfectly), and to write in the specification of TAP clearly since it is not good to introduce the syntax in which it is new for a subtest, in the viewpoint of backward compatibility.

if it is defined as the spec of TAP like Directive, such as TODO and SKIP, and is good to parse mechanically.


# Subtest Start subtest1...
    1..1
    ok 1 - sub test1
ok 1 - subtest1

If the comment starts with # Subtest start, the subtest is started....


@exodist
Owner

Here is a question for everyone with stake in this.

The problem seems to be that the final ok - NAME is after the indented ok - SUBTEST ok:

ok - BEFORE SUBTEST
  # Subtest: NAME (This is the comment the pull request is for)
    ok - INSIDE SUBTEST
    ok - ALSO INSIDE
ok - SUBTEST RESULT

Which is really not intuitive.

How would everyone feel about this change?

ok - BEFORE SUBTEST
ok - SUBTEST RESULT (subtest result comes BEFORE it's inner-events)
    ok - INSIDE SUBTEST
    ok - ALSO INSIDE
    # end (This comment comes at the end of the subtest results, and will be indented)

The reason I ask is because I have a few new behaviors which I am introducing with a 'modern' argument when you load Test::More. This is the perfect opportunity to introduce this behavior. Legacy code will not have the 'modern' argument and will not break. But for those of us who want it to make more sense will be able to just turn on modern features.

I also pondered adding a 'tree' option which shows the sub-events with a more distinct tree notation, but I ditched it fairly quick as overkill.

I have this all implemented in my personal tree, I am working on fixing some failing tests, then I will merge it, but it is still a while before a stable release, so there is time to change it if opinion is against it.

@dagolden
ok - BEFORE SUBTEST
ok - SUBTEST RESULT (subtest result comes BEFORE it's inner-events)
    ok - INSIDE SUBTEST
    ok - ALSO INSIDE
    # end (This comment comes at the end of the subtest results, and will be indented)

That seems lovely to me. I'd like to make sure that an error in the subtest doesn't lose information -- I'd still want to see output up to the point of error.

@haarg
Collaborator

This causes problems if you have slow running tests and use subtests. You wouldn't be able to see any results until the entire subtest finished. Things using Test::Class::Moose for example would not output anything until all of the tests for a class were run.

Also, while generally using diag/note are preferred ways to output extra data, printing to STDOUT/STDERR would not line up with the other output at all. This includes warnings emitted by perl.

@tobyink
ok - some other test
vv - this has subtests
    ok - foo
    ok - bar
    ok - baz
ok - this has subtests

Technically that vv line is invalid TAP, but TAP consumers are supposed to ignore lines they don't understand. What is "vv" an abbreviation for? "verification vnderneath" perhaps, or maybe it just looks like a couple of arrows pointing down at where the test result is.

@exodist
Owner

Stdout and stderr already do not line up most of the time. That said I do have some things in mind to help mitigate that.

As for the problem of nothing printing until after it is complete, I will make sure this is all configurable, the default will be changed as little as possible, enhancements that could break things will need to be turned on.

@dagolden

@tobyink that's what the outdented comment was intended for

@exodist
Owner

276d41b

This commit lets you configure how subtest output is done.

use Test::More subtest_tap => $OPTION;

Options are:

  • none - don't display inner results, just the final ok
  • instant - legacy style, default
  • delayed - new style, I will show below
  • both - do both, which is kinda silly

Example script:

use Test::More subtest_tap => ...;
use strict;
use warnings;

ok(1, "fine");

subtest my_subtest => sub {
    ok(1, "inside 1");
    ok(1, "inside 2");
};  

subtest another_subtest => sub {
    ok(1, "inside 1");
    subtest deeper => sub {
        ok(1, "pass");
        ok(0, "fail");
        ok(1, "pass");
    };  
    ok(1, "inside 2");
};  

ok(1, "after");

done_testing;

Here is the output with the option 'instant' (Note output is when called with perl, prove might change the output because of buffering)

ok 1 - fine
# Subtest: my_subtest
    ok 1 - inside 1
    ok 2 - inside 2
    1..2
ok 2 - my_subtest
# Subtest: another_subtest
    ok 1 - inside 1
    # Subtest: deeper
        ok 1 - pass
        not ok 2 - fail
        #   Failed test 'fail'
        #   at test.pl line 16.
        ok 3 - pass
        1..3
        # Looks like you failed 1 test of 3.
    not ok 2 - deeper
    #   Failed test 'deeper'
    #   at test.pl line 18.
    ok 3 - inside 2
    1..3
    # Looks like you failed 1 test of 3.
not ok 3 - another_subtest
#   Failed test 'another_subtest'
#   at test.pl line 20.
ok 4 - after
1..4
# Looks like you failed 1 test of 4.

Here is the delayed option (once again, run with perl directly, prove makes the STDERR bits come at the end :-1: )

ok 1 - fine
ok 2 - my_subtest {
    ok 1 - inside 1
    ok 2 - inside 2
    1..2
}
not ok 3 - another_subtest {
#   Failed test 'another_subtest'
#   at test.pl line 20.
    ok 1 - inside 1
    not ok 2 - deeper {
    #   Failed test 'deeper'
    #   at test.pl line 18.
        ok 1 - pass
        not ok 2 - fail
        #   Failed test 'fail'
        #   at test.pl line 16.
        ok 3 - pass
        1..3
        # Looks like you failed 1 test of 3.
    }
    ok 3 - inside 2
    1..3
    # Looks like you failed 1 test of 3.
}
ok 4 - after
1..4
# Looks like you failed 1 test of 4.

I might be convinced that the # Failed test 'another_subtest' belongs after the closing bracket... it is also not too hard to do.

@exodist
Owner

oops, looks like I broke 2 test files. fixing.

@exodist
Owner

fixed in f210edd

@exodist
Owner

@dagolden Interested in your feedback on those outputs. I am not married to using brackets.

@dagolden

I'm not sold that this should be configurable. I feel like Test::More is taking on too much of a role in TAP formatting, which seems like should really be a harness-level issue.

My reaction to 'delayed' is that after the opening "{", the "# Failed" isn't indented, which is confusing, so I'd put it after the closing "}". I'm not sold on the brackets at all -- I'd rather see this handled with indentation.

Part of the reason for my hesitation is that I'd like to do something that could plausibly become part of TAP itself eventually, and I'm not sure this is it. I'm not sure it's not, either. :-/ Sorry.

@exodist
Owner

@dagolden don't be sorry, this discussion is important. There is still plenty of time before I take this out of alpha, so there is plenty of time to change things.

I do think the failure diag for the subtests should come after the closing bracket, assuming the brackets stay.

As for the brackets, I had a thought overnight, what if we prefix the opening bracket with a '#' turning it into a directive similar to ok 1 - xxx # todo/skip becoming ok 1 - xxx # { that seems to me like something that could be integrated into TAP to let it know the test is a subtest, and to expect some indented sub-tap. the closing bracket would then be an easy indicator that the sub-tap is done.

Anyway, I am not pushing this from the perspective of being sold and adamant, just putting ideas out there. Nothing is set in stone until a stable ships :-).

@dagolden

How about "# subtest {" as the TAP directive with a matching "# } $name" close?

ok 1 - frob the lamp # subtest {
    ok 1 - inside 1
    ok 2 - inside 2
    1..2
# } frob the lamp

Or even without the brackets:

ok 1 - frob the lamp # subtest
    ok 1 - inside 1
    ok 2 - inside 2
    1..2
# frob the lamp
@exodist
Owner

I am fine with either of those.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Apr 28, 2014
  1. @dagolden

    Outdent subtest intro comment

    dagolden authored
    This commit puts the subtest intro comment at the parent indent level.
    
    Before:
    
        ok 1 - regular test
            # Subtest: my first subtest
            ok 1 - first test
            ok 2 - second test
            ok 3 - third test
            1..3
        ok 2 - my first subtest
    
    After:
    
        ok 1 - regular test
        # Subtest: my first subtest
            ok 1 - first test
            ok 2 - second test
            ok 3 - third test
            1..3
        ok 2 - my first subtest
    
    I think this is much easier to read because it brackets the subtest
    information at the same indentation level.  The subtest details are
    clearly between the opening comment and the matching "ok".
This page is out of date. Refresh to see the latest.
View
5 lib/Test/Builder.pm
@@ -247,14 +247,15 @@ sub subtest {
# $Level first to limit the scope of the reset to the subtest.
local $Test::Builder::Level = $Test::Builder::Level + 1;
+ # Add subtest name for clarification of starting point
+ $self->note("Subtest: $name");
+
# Store the guts of $self as $parent and turn $child into $self.
$child = $self->child($name);
_copy($self, $parent);
_copy($child, $self);
my $run_the_subtests = sub {
- # Add subtest name for clarification of starting point
- $self->note("Subtest: $name");
$subtests->();
$self->done_testing unless $self->_plan_handled;
1;
View
4 t/subtest/bail_out.t
@@ -46,10 +46,10 @@ subtest 'bar' => sub {
$Test->is_eq( $output, <<'OUT' );
1..4
ok 1
- # Subtest: bar
+# Subtest: bar
1..3
ok 1
- # Subtest: sub_bar
+ # Subtest: sub_bar
1..3
ok 1
ok 2
View
10 t/subtest/line_numbers.t
@@ -26,7 +26,7 @@ $ENV{HARNESS_ACTIVE} = 0;
our %line;
{
- test_out(" # Subtest: namehere");
+ test_out("# Subtest: namehere");
test_out(" 1..3");
test_out(" ok 1");
test_out(" not ok 2");
@@ -47,7 +47,7 @@ our %line;
test_test("un-named inner tests");
}
{
- test_out(" # Subtest: namehere");
+ test_out("# Subtest: namehere");
test_out(" 1..3");
test_out(" ok 1 - first is good");
test_out(" not ok 2 - second is bad");
@@ -78,7 +78,7 @@ sub run_the_subtest {
}; BEGIN{ $line{outerfail3} = __LINE__ }
}
{
- test_out(" # Subtest: namehere");
+ test_out("# Subtest: namehere");
test_out(" 1..3");
test_out(" ok 1 - first is good");
test_out(" not ok 2 - second is bad");
@@ -95,7 +95,7 @@ sub run_the_subtest {
test_test("subtest() called from a sub");
}
{
- test_out( " # Subtest: namehere");
+ test_out( "# Subtest: namehere");
test_out( " 1..0");
test_err( " # No tests run!");
test_out( 'not ok 1 - No tests run for subtest "namehere"');
@@ -109,7 +109,7 @@ sub run_the_subtest {
test_test("lineno in 'No tests run' diagnostic");
}
{
- test_out(" # Subtest: namehere");
+ test_out("# Subtest: namehere");
test_out(" 1..1");
test_out(" not ok 1 - foo is bar");
test_err(" # Failed test 'foo is bar'");
View
12 t/subtest/predicate.t
@@ -40,7 +40,7 @@ sub foobar_ok ($;$) {
};
}
{
- test_out(" # Subtest: namehere");
+ test_out("# Subtest: namehere");
test_out(" 1..2");
test_out(" ok 1 - foo");
test_out(" not ok 2 - bar");
@@ -65,7 +65,7 @@ sub foobar_ok_2 ($;$) {
foobar_ok($value, $name);
}
{
- test_out(" # Subtest: namehere");
+ test_out("# Subtest: namehere");
test_out(" 1..2");
test_out(" ok 1 - foo");
test_out(" not ok 2 - bar");
@@ -95,7 +95,7 @@ sub barfoo_ok ($;$) {
});
}
{
- test_out(" # Subtest: namehere");
+ test_out("# Subtest: namehere");
test_out(" 1..2");
test_out(" ok 1 - foo");
test_out(" not ok 2 - bar");
@@ -120,7 +120,7 @@ sub barfoo_ok_2 ($;$) {
barfoo_ok($value, $name);
}
{
- test_out(" # Subtest: namehere");
+ test_out("# Subtest: namehere");
test_out(" 1..2");
test_out(" ok 1 - foo");
test_out(" not ok 2 - bar");
@@ -138,10 +138,10 @@ sub barfoo_ok_2 ($;$) {
# A subtest-based predicate called from within a subtest
{
- test_out(" # Subtest: outergroup");
+ test_out("# Subtest: outergroup");
test_out(" 1..2");
test_out(" ok 1 - this passes");
- test_out(" # Subtest: namehere");
+ test_out(" # Subtest: namehere");
test_out(" 1..2");
test_out(" ok 1 - foo");
test_out(" not ok 2 - bar");
View
2  t/subtest/todo.t
@@ -52,7 +52,7 @@ sub test_subtest_in_todo {
my ($set_via, $todo_reason, $level) = @$combo;
test_out(
- " # Subtest: xxx",
+ "# Subtest: xxx",
@outlines,
"not ok 1 - $xxx # TODO $todo_reason",
"# Failed (TODO) test '$xxx'",
Something went wrong with that request. Please try again.