I've been a long-term user of test cases for my own code, as that gives me confidence that my code is good - or at the very least that changes I introduce haven't broken things too much!
My test-cases, in general, have been fairly straightforward in nature, and have worked without issues. As a matter of course I try to document the requirements of my code via a test case modules.t, which should ensure that anybody who can make the test case run successfully (via "make test") has all the modules required.
Here is an explicit example:
#!/usr/bin/perl -w -I.. # # Test that all the Perl modules we require are available. # (This list is automatically generated.) use Test::More qw( no_plan ); # ... BEGIN{ use_ok( 'CGI' ); } require_ok( 'CGI' ); BEGIN{ use_ok( 'Date::Format' ); } require_ok( 'Date::Format' ); BEGIN{ use_ok( 'POSIX' ); } require_ok( 'POSIX' ); # ... # ...
This test is part of a series which runs, via cron, on a daily basis. Unfortunately the combination of modules which I'm testing for give me a whole bunch of spam on STDERR:
skx@gold:~$ perl t.t > /dev/null Subroutine main::ctime redefined at (eval 4) line 2 Prototype mismatch: sub main::ctime ($;$) vs none at (eval 4) line 2 Subroutine main::strftime redefined at (eval 4) line 2 Prototype mismatch: sub main::strftime ($\@;$) vs none at (eval 4) lin +e 2 Subroutine main::asctime redefined at (eval 4) line 2 Prototype mismatch: sub main::asctime (\@;$) vs none at (eval 4) line +2
So, my question. Is it possible for me to avoid these errors whilst still working in the "standard" way when it comes to using Test::More and testing module availability?
(Certainly I accept that making my crontab entry throw away STDERR would solve my immediate problem, but it might hide things from me in the future.)
In reply to Issues when testing module loading by skx
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |