Wetware::Test::CreateTestSuite - for creating TestSuite.pm
use Wetware::Test::CreateTestSuite; my $test_stuite_creator = Wetware::Test::CreatTestSuite->new( %{$options} ); $test_stuite_creator->run();
The goal: automate the process of creating a Test::Class based TestSuite.pm for each module Foo. So that there will be at least a Foo::TestSuite.pm frame that will have a working test_new() method.
It will also seek to install into the t/ of the "search_dir" the three basic scripts.
The new 01_test_class.t script requires that there is the Wetware::Test::Class::Load that will skip over the CVS and .svn directories that may get copied into blib/lib from lib by the basic Module::Build process.
Constructs the immutable CreateTestSuite object.
At present I do not see a good reason for any other public methods.
Since it just needs to be constructed and run.
It will exit with the normal exit value for unix of '0'.
This is the list of mostly private methods, but are listed so that IF anyone comes up with a good case to subclass this...
Given a list of pm_paths, write the TestSuite.pm.
Nice slurp the data in.
accessor to preview.
Calls find_pm() to get a list of pm in the $dir.
find_pm()
It then filgers out those that are TestSuite.pm, or have a TestSuite.pm module.
The list returned is those that will need to have one added.
Writes out the alternative .t files into t/. These files are:
.t
t/
00_compile_pm.t
01_test_class.t
pod-coverage.t
Note, these will not overwrite existing files, so IF this is run after module-starter has installed the default pod-coverage.t that file should be removed first.
TODO: what if we had a cli option for this? some sort of --t_files_only
TBD
wrapper on Wetware::Test::Utilities::is_testsuite_module;
Constructs the path to the Foo::TestSuite, given the path to the Foo Module. Then uses the file path to the TestSuite to call is_testsuite().
is_testsuite()
It will short circuit, if there is no Foo directory.
A wrapper on File::Find:find() that has both a wanted() and a preprocess() method passed in as an option.
It will currently skip over any directory that is begins with 'CVS', '.svn' and any that begins with a '.'.
Accessor that returns the search directory.
returns the path to where the t/ is expected to be.
Accessor to named command line value.
Given the directory where TestSuite.pm is to be written, the pkg_name it will test, and a list of subnames, write out the TestSuite.pm file itself.
There is a debate about whether or not we should have a get_resources_from_INC() method that would find these as template files..... instead of having these three hereto document methods....
If we shift to a get_resources_from_INC() approach, then these will be the access methods to that solution.
Creates the content for the test_SUBNAME() sub.
Returns a set of stock use lines.
Adds a test_new() and a commented out test_methodNameHere() method.
There are two semi standard .t test scripts that need to be changed to work and play well with the TestSuite approach, since if one attempts to do the simple Test::Compile of any Module that inherits from a Test::Class based module with the INIT block, they will fail becaue 'it is too late for INIT' - this is also true of Pod Coverage.
So the fix is to call a sub.
Modify pod-coverage.t to use:
all_non_testsuite_pod(); #------------------------------------------------------------- sub all_non_testsuite_pod { my @modules = grep { $_ !~ m{::TestSuite$} } all_modules(); plan tests => scalar @modules; foreach my $module ( @modules ) { pod_coverage_ok($module); } return; }
And it will filter out the modules *::TestSuite.
The compile_pm script is about the same, except that it runs with module file names:
all_non_testsuite_modules(); #---------------------------------------------------------------- sub all_non_testsuite_modules { my @modules = grep { $_ !~ m{/TestSuite.pm$} } all_pm_files(); plan tests => scalar @modules; foreach my $module ( @modules ) { pm_file_ok ($module); } return; }
You can download this module from the CPAN and look at the t/ directory for the specific test files.
"drieux", <"drieux [AT] at wetware.com">
<"drieux [AT] at wetware.com">
Please report any bugs or feature requests to bug-wetware-test-createtestsuite at rt.cpan.org, or through the web interface at http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Wetware-Test-CreateTestSuite. I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.
bug-wetware-test-createtestsuite at rt.cpan.org
You can find documentation for this module with the perldoc command.
perldoc Wetware::Test::CreateTestSuite
You can also look for information at:
RT: CPAN's request tracker
http://rt.cpan.org/NoAuth/Bugs.html?Dist=Wetware-Test-CreateTestSuite
AnnoCPAN: Annotated CPAN documentation
http://annocpan.org/dist/Wetware-Test-CreateTestSuite
CPAN Ratings
http://cpanratings.perl.org/d/Wetware-Test-CreateTestSuite
Search CPAN
http://search.cpan.org/dist/Wetware-Test-CreateTestSuite/
Copyright 2009 "drieux", all rights reserved.
This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
To install Wetware::Test::CreateTestSuite, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Wetware::Test::CreateTestSuite
CPAN shell
perl -MCPAN -e shell install Wetware::Test::CreateTestSuite
For more information on module installation, please visit the detailed CPAN module installation guide.