|
NAMETest::Manifest - interact with a t/test_manifest fileSYNOPSIS# in Makefile.PL eval "use Test::Manifest 2.00"; # in Build.PL my $class = do { if( eval 'use Test::Manifest 2.00; 1' ) { Test::Manifest->get_module_build_subclass; } else { 'Module::Build'; } }; my $build = $class->new( ... ) # in the file t/test_manifest, list the tests you want # to run in the order you want to run them DESCRIPTION"Test::Harness" assumes that you want to run all of the .t files in the t/ directory in ASCII-betical order during "make test" or "./Build test" unless you say otherwise. This leads to some interesting naming schemes for test files to get them in the desired order. These interesting names ossify when they get into source control, and get even more interesting as more tests show up."Test::Manifest" overrides the default test file order. Instead of running all of the t/*.t files in ASCII-betical order, it looks in the t/test_manifest file to find out which tests you want to run and the order in which you want to run them. It constructs the right value for the build system to do the right thing. In t/test_manifest, simply list the tests that you want to run. Their order in the file is the order in which they run. You can comment lines with a "#", just like in Perl, and "Test::Manifest" will strip leading and trailing whitespace from each line. It also checks that the specified file is actually in the t/ directory. If the file does not exist, it does not put its name in the list of test files to run and it will issue a warning. Optionally, you can add a number after the test name in test_manifest to define sets of tests. See "get_t_files" for more information. ExtUtils::MakeMakerTo override the test order behaviour in "MakeMaker", "Test::Manifest" inserts itself in the "test_via_harness" step by providing its own test runner. In "Makefile.PL", all you have to do is load "Test::Manifest" before you call "WriteMakefile". To make it optional, load it in an eval:eval "use Test::Manifest"; Module::BuildOveriding parts of "Module::Build" is tricker if you want to use the subclassing mechanism and still make "Test::Manifest" optional. If you can load "Test::Manifest" (version 2.00 or later), "Test::Manifest" can create the subclass for you.my $class = do { if( eval 'use Test::Manifest 2.00; 1' ) { Test::Manifest->get_module_build_subclass; } else { 'Module::Build' # if Test::Manifest isn't there } }; $class->new( ... ); $class->create_build_file; This is a bit of a problem when you already have your own subclass. "Test::Manifest" overrides "find_test_files", so you can get just that code to add to your own subclass code string: my $code = eval 'use Test::Manifest 2.00; 1' ? Test::Manifest->get_module_build_code_string : ''; my $class = Module::Build->subclass( ..., code => "$code\n...your subclass code string...", ); Class methods
Functions
SOURCE AVAILABILITYThis source is in Github:http://github.com/briandfoy/test-manifest/ CREDITSMatt Vanderpol suggested and supplied a patch for the ";include" feature.Olivier Mengué supplied a documentation patch. AUTHORbrian d foy, "<bdfoy@cpan.org>"COPYRIGHT AND LICENSECopyright © 2002-2022, brian d foy <bdfoy@cpan.org>. All rights reserved.This program is free software; you can redistribute it and/or modify it under the terms of the Artistic License 2.0.
Visit the GSP FreeBSD Man Page Interface. |