Some reflow, refs #2683

Author: JJ

doc/Type/Test.pod6

@@ -71,10 +71,10 @@ Specify that testing has finished.  Use this function when you don't
 have a C<plan> with the number of tests to run. A C<plan> is not
 required when using C<done-testing>.
 
-It's recommended that the C<done-testing> function be removed and replaced
-with a C<plan> function when all tests are finalized. Use of C<plan> can help
-detect test failures otherwise not reported because tests were accidentally skipped
-due to bugs in the tests or bugs in the compiler. For example:
+It's recommended that the C<done-testing> function be removed and replaced with
+a C<plan> function when all tests are finalized. Use of C<plan> can help detect
+test failures otherwise not reported because tests were accidentally skipped due
+to bugs in the tests or bugs in the compiler. For example:
 
     sub do-stuff {@};
     use Test;
@@ -85,8 +85,9 @@ due to bugs in the tests or bugs in the compiler. For example:
     1..0
 
 The above example is where a C<done-testing> fails. C<do-stuff()> returned
-nothing and tested nothing, even though it should've returned results to test. But
-the test suite doesn't know how many tests were meant to be run, so it passes.
+nothing and tested nothing, even though it should've returned results to test.
+But the test suite doesn't know how many tests were meant to be run, so it
+passes.
 
 Adding C<plan> gives a true picture of the test:
 
@@ -166,9 +167,10 @@ L«C<is-deeply> routine|/language/testing#index-entry-is-deeply-is-deeply($value
     my Int $a;
     is $a, Int, 'The variable $a is an unassigned Int';
 
-B<Note:> if I<only> whitespace differs between the values, C<is()> will output failure
-message differently, to show the whitespace in each values. For example, in the
-output below, the second test shows the literal C<\t> in the C<got:> line:
+B<Note:> if I<only> whitespace differs between the values, C<is()> will output
+failure message differently, to show the whitespace in each values. For example,
+in the output below, the second test shows the literal C<\t> in the C<got:>
+line:
 
 =for code
 is "foo\tbar", "foo\tbaz";   # expected: 'foo     baz'␤#      got: 'foo   bar'
@@ -512,7 +514,7 @@ sub saruman(Bool :$ents-destroy-isengard) {
 dies-ok { saruman(ents-destroy-isengard => True) }, "Saruman dies";
 =end code
 
-=head2 lives-ok
+=head2 sub lives-ok
 
 Defined as:
 
@@ -531,7 +533,7 @@ sub frodo(Bool :$destroys-ring) {
 lives-ok { frodo(destroys-ring => True) }, "Frodo survives";
 =end code
 
-=head2 eval-dies-ok
+=head2 sub eval-dies-ok
 
 Defined as:
 
@@ -548,7 +550,7 @@ eval-dies-ok q[my $joffrey = "nasty";
     "Ned Stark dies";
 =end code
 
-=head2 eval-lives-ok
+=head2 sub eval-lives-ok
 
 Defined as:
 
@@ -565,7 +567,7 @@ eval-lives-ok q[my $daenerys-burns = False;
     "Dany is blood of the dragon";
 =end code
 
-=head2 throws-like
+=head2 sub throws-like
 
 Defined as:
 
@@ -593,38 +595,41 @@ positional argument.
 The routine makes L<Failures|/type/Failure> fatal. If you wish to avoid that,
 use L«C<no fatal> pragma|/language/pragmas#index-entry-fatal-fatal» and ensure
 the tested code does not sink the possible L<Failures|/type/Failure>. If you
-wish to test that the code returns a L<Failure|/type/Failure> instead of throwing, use
-C<fails-like> routine instead.
+wish to test that the code returns a L<Failure|/type/Failure> instead of
+throwing, use C<fails-like> routine instead.
 
-    sub fails-not-throws { +"a" }
-    # test passes, even though it's just a Failure and would not always throw:
-    throws-like { fails-not-throws }, Exception;
+=begin code
+sub fails-not-throws { +"a" }
+# test passes, even though it's just a Failure and would not always throw:
+throws-like { fails-not-throws }, Exception;
 
-    # test detects nothing got thrown, because our Failure wasn't sunk or made fatal:
-    throws-like { no fatal; my $ = fails-not-throws; Nil }, Exception;
+# test detects nothing thrown, because our Failure wasn't sunk or made fatal:
+throws-like { no fatal; my $ = fails-not-throws; Nil }, Exception;
+=end code
 
-Please note that you can only use the string form (for C<EVAL>) if you are not referencing
-any symbols in the surrounding scope. If you are, you should encapsulate
-your string with a block and an EVAL instead. For instance:
+Please note that you can only use the string form (for C<EVAL>) if you are not
+referencing any symbols in the surrounding scope. If you are, you should
+encapsulate your string with a block and an EVAL instead. For instance:
 
     throws-like { EVAL q[ fac("foo") ] }, X::TypeCheck::Argument;
 
-=head2 fails-like
+=head2 sub fails-like
 
 Defined as:
 
-    sub fails-like ( \test where Callable:D|Str:D, $ex-type, $reason?, *%matcher)
+=for code
+sub fails-like ( \test where Callable:D|Str:D, $ex-type, $reason?, *%matcher)
 
 Same interface as C<throws-like>, except checks that the code returns a
-L<Failure|/type/Failure> instead of throwing. If the code does throw or if the returned
-L<Failure|/type/Failure> has already been L<handled|/routine/handled>, that will be considered as a failed
-test.
+L<Failure|/type/Failure> instead of throwing. If the code does throw or if the
+returned L<Failure|/type/Failure> has already been L<handled|/routine/handled>,
+that will be considered as a failed test.
 
     fails-like { +"a" }, X::Str::Numeric,
         :message(/'Cannot convert string to number'/),
     'converting non-numeric string to number fails';
 
-=head2 subtest
+=head2 sub subtest
 
 Defined as:
 
@@ -656,8 +661,9 @@ subtest {
 }, "Check Great Uncle Bulgaria";
 =end code
 
-You can also place the description as the first positional argument, or use a C<Pair> with description as the key and subtest's code
-as the value. This can be useful for subtests with large bodies.
+You can also place the description as the first positional argument, or use a
+C<Pair> with description as the key and subtest's code as the value. This can be
+useful for subtests with large bodies.
 
 =begin code
 subtest 'A bunch of tests', {
@@ -673,8 +679,7 @@ subtest 'Another bunch of tests' => {
 }
 =end code
 
-
-=head2 todo
+=head2 sub todo
 
 Defined as:
 
@@ -709,7 +714,7 @@ Note that if you C<todo> a C<subtest>, all of the failing tests inside of it
 will be automatically marked TODO as well and will I<not> count towards your
 original TODO count.
 
-=head2 skip
+=head2 sub skip
 
 Defined as:
 
@@ -735,7 +740,7 @@ else {
 Note that if you mark a test as skipped, you must also prevent that
 test from running.
 
-=head2 skip-rest
+=head2 sub skip-rest
 
 Defined as:
 
@@ -767,7 +772,7 @@ to avoid running any tests at all and
 L«C<bail-out>|/language/testing#index-entry-bail-out-bail-out($reason?)» to abort
 the test run and mark it as failed.
 
-=head2 bail-out
+=head2 sub bail-out
 
     sub bail-out ($desc?)
 
@@ -788,7 +793,7 @@ If you want to abort the test run, but without marking it as failed, see
 L«C<skip-rest>|/language/testing#index-entry-skip-rest-skip-rest($reason?)»
 or L«C<plan :skip-all('...')>|/language/testing#index-entry-plan-plan($count)»
 
-=head2 pass
+=head2 sub pass
 
 Defined as:
 
@@ -805,13 +810,13 @@ Since these subroutines do not provide indication of what value was received
 and what was expected, they should be used sparingly, such as when evaluating
 a complex test condition.
 
-=head2 flunk
+=head2 sub flunk
 
     multi sub flunk($reason = '')
 
 The opposite of C<pass>, makes a test fail with an optional message.
 
-=head2 diag
+=head2 sub diag
 
     sub diag($message)