>which pp requires M::SD to do correctly.
>Any suggestions?
For testing manifest/M::SD, one thing that comes to mind is to have a
test suite wherein a number of test-purposes-only modules are created in
a number of test-purposes-only subdirectories, and have those
subdirectories be in the (@INC?) path. Then include the said modules in
a .pl file that the test suite writes, and generate an executable using
them all. M::SD should find the other modules, etcetera.
In order to check the results, such as a list of modules that should
have been picked up by M::SD, the expected list must be known
beforehand. That precludes a lot of CPAN modules because they often
change, which would break the tests. For example the quite stable Tk
has quite a few modules it depends upon. As the very recent rt ticket
below shows there are now three modules that it no longer uses. At
least not by default.
Re: [rt.cpan.org #24323] Cannot open : No such file or directory at
C:/perl/site/lib/Module/ScanDeps.pm line 477.
To save you the time of looking up rt.cpan.org #24323, the three said
modules are
tk::WinPhoto
tk::Mwm
Tk::InputO
So ... if an M::SD test was already written that included any of the Tk
modules as part of it's test, it would now be broken. Hence the need
for a lot of test-purposes-only modules.
I hope this helps.
Eric Wilhelm wrote:
Hello par users,
I'm looking at a few things in the guts of Module::ScanDeps and could
really use some suggestions, sample data, and volunteers to flesh out
the test suite.
I notice that PAR::Packer has quite a few pp tests in the contrib dir,
but they don't seem to check that the executable runs, content of
manifest, and various other things which pp requires M::SD to do
correctly. Besides not really providing much coverage, it also
introduces a lot of overhead into the tests.
Any suggestions? Particularly, _compile() and _execute() need some
love. Also, all of the module-specific knowledge in %Preload sort of
scares me. How to get test coverage on that?
Thanks,
Eric
