Contradictory advice and test on using Test::More #13231
Comments
From @SmylersThis is a bug report for perl from smylers@stripey.com, perlhack, in its TESTING section, says that tests other than in specific But t/porting/test_bootstrap.t specifically tests that no t/**.t files use Test::More; into a test in t/porting/ (not one of the directories perlhack mentions These obviously contradict each other, and I don't know what should be Either test_bootstrap.t needs restricting to the directories mentioned Flags: Site configuration information for perl 5.19.4: Configured by smylers at Tue Sep 3 10:58:31 BST 2013. Summary of my perl5 (revision 5 version 19 subversion 4) configuration: @INC for perl 5.19.4: Environment for perl 5.19.4: |
From @jkeenanOn Thu Sep 05 04:44:55 2013, smylers@stripey.com wrote:
I can confirm that adding or editing a file in t/porting which contains Would the patch attached suffice? Thank you very much. |
From @jkeenan0001-Add-t-porting-to-list-of-directories-which-use-t-tes.patchFrom c0f09e3f907fe356fdf7d7ac36c9bea024894e0d Mon Sep 17 00:00:00 2001
From: James E Keenan <jkeenan@cpan.org>
Date: Fri, 6 Sep 2013 01:12:30 +0200
Subject: [PATCH] Add t/porting to list of directories which use t/test.pl.
For: RT #119619
---
pod/perlhack.pod | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/pod/perlhack.pod b/pod/perlhack.pod
index ff685d2..028849c 100644
--- a/pod/perlhack.pod
+++ b/pod/perlhack.pod
@@ -754,7 +754,7 @@ tested. Tests in F<t/opbasic>, for instance, have been placed there
rather than in F<t/op> because they test functionality which
F<t/test.pl> presumes has already been demonstrated to work.
-=item * F<t/cmd>, F<t/run>, F<t/io> and F<t/op>
+=item * F<t/cmd>, F<t/run>, F<t/io>, F<t/op> and F<t/porting>
Now that basic require() and subroutines are tested, you can use the
F<t/test.pl> library.
--
1.7.1
|
|
The RT System itself - Status changed from 'new' to 'open' |
From @SmylersJames E Keenan via RT writes:
Note that t/porting/ is simply an example which demonstrates the Here's the relevant text from perlhack: · t/base, t/comp and t/opbasic ... use ad hoc tests for these three ... Now that basic require() and subroutines are tested, you can use · Everything else Now that the core of Perl is tested, Test::More can and should be And here are t/ subdirectories which include .t files but aren't lib x2p benchmark mro bigmem porting uni japh re test_pl win32
That patch simply moves t/porting into the second bullet point's list, As far as I can tell, test_bootstrap.t prevents any test in t/ from So making the documentation consistent with test_bootstrap.t would But it isn't clear to me that that's the right thing to do. The author So before any solution can be effected, somebody needs to make a Cheers Smylers |
|
This contradiction still exists in blead: perlhack says to use Given tests seem to be existing without using |
Since the last time we discussed this issue was more than six years ago, I'll have to re-read the ticket to respond adequately. Thank you very much. |
As reported by Smylers in RT 119619 (now GH 13231), the guidance provided in 'perlhack' for usage of Test::More is misleading. In practice, we do not use Test::More in test files in the subdirectories underneath 't/'. In these directories we test Perl 5's "pre-modular" functionality -- functionality which does not depend on our having demonstrated that we can load code via 'use MODULE'. Usage of 'use MODULE' in 't/*/*.t' files has been largely prohibited by a unit test in t/porting/bootstrap.t. This patch clarifies that guidance. For: #13231
One of the objectives of t/porting/bootstrap.t has been to prohibit use of testing modules which need to be loaded via 'use MODULE' in test files found in subdirectories under 't/'. In those subdirectories, we do not presume that module loading via 'use MODULE' has been demonstrated to work. However, the unit test in bootstrap.t was written solely to spot instances of 'use Test::More'. It did not consider the possibility that a test file under 't/' might 'use Test::Simple'. There was one such test file which use-d Test::Simple: t/lib/overload_nomethod.t. This patch rewrites that file to use 't/test.pl' (as other t/lib/*.t files customarily do) and adapts t/porting/bootstrap.t to rule out 'use Test::Simple' as well as 'use Test::More' from '*.t' files underneath 't/'. For: #13231
I've now re-read this ticket and believe I understand your points. In the first patch in the In the course of demonstrating to myself the correctness of your argument, I found one gotcha: a test under Please review. Thank you very much. |
|
See: #17524 |
As reported by Smylers in RT 119619 (now GH 13231), the guidance provided in 'perlhack' for usage of Test::More is misleading. In practice, we do not use Test::More in test files in the subdirectories underneath 't/'. In these directories we test Perl 5's "pre-modular" functionality -- functionality which does not depend on our having demonstrated that we can load code via 'use MODULE'. Usage of 'use MODULE' in 't/*/*.t' files has been largely prohibited by a unit test in t/porting/bootstrap.t. This patch clarifies that guidance. POD correction per Tony Cook For: #13231
One of the objectives of t/porting/bootstrap.t has been to prohibit use of testing modules which need to be loaded via 'use MODULE' in test files found in subdirectories under 't/'. In those subdirectories, we do not presume that module loading via 'use MODULE' has been demonstrated to work. However, the unit test in bootstrap.t was written solely to spot instances of 'use Test::More'. It did not consider the possibility that a test file under 't/' might 'use Test::Simple'. There was one such test file which use-d Test::Simple: t/lib/overload_nomethod.t. This patch rewrites that file to use 't/test.pl' (as other t/lib/*.t files customarily do) and adapts t/porting/bootstrap.t to rule out 'use Test::Simple' as well as 'use Test::More' from '*.t' files underneath 't/'. For: #13231
Migrated from rt.perl.org#119619 (status was 'open')
Searchable as RT119619$
The text was updated successfully, but these errors were encountered: