Test::Resub handles this. We use this extensively in our test suites at work. In your test:
#!/usr/bin/perl use Your::Module; use Proc::Background; use Test::Resub qw(resub); # disable Proc::Background->new for the scope of this block { my $fake_new = sub { return bless {}, 'Proc::Background'; # or whatever }; my $resub = resub 'Proc::Background::new', $fake_new; # continue on your merry way, content knowing that # your $fake_new is getting called. } # scope of $resub object ends, its DESTROYER restores # the original Proc::Background::new.
Probably you'd want to have a single resub ofProc::Background::new up high in your test, so you don't need to keep creating the resub.

Test::Resub allows you to capture the arguments that go to your resubbed code. For example, consider this helper function

package My::Module; use IO::Socket::INET; ... sub open_socket_to { my ($class, %args) = @_; return IO::Socket::INET->new( PeerAddr => $args{machine}, PeerPort => $args{port}, Proto => $args{protocol} || 'tcp', Type => SOCK_STREAM, ); }
Not only would it be nice to prevent the test from actually creating sockets, it would be good to know how we're creating those sockets. The test might look like this

use Test; ... use My::Module; use Test::Resub qw(resub); use IO::Socket::INET; # test open_socket_to { my $rs = resub 'IO::Socket::INET::new', sub { 'a socket' }, captur +e => 1; my $socket = My::Module->open_socket_to( machine => 'example.com', port => '-29', ); # return value of ->open_socket_to is whatever IO::Socket::INET::n +ew gives us ok( $socket, 'a socket' ); # We created the socket correctly - the fact that we provided an # illegal PeerPort doesn't need to be handled by this test: # IO::Socket::INET should have his own tests for his ->new. is_deeply( $rs->named_method_args, [{ PeerAddr => 'example.com', PeerPort => -29, Proto => 'tcp', Type => SOCK_STREAM, }] ); }
Sometimes you might find you want to allow the original code to run, but you want to eavesdrop in on the arguments that get sent in to it. Test::Wiretap handles that.

You can have multiple resubs and wiretaps in place for the same subroutine: they'll stack properly and unroll correctly.


In reply to Re: Overriding a module that is used by a program I'm testing by belden
in thread Overriding a module that is used by a program I'm testing by Narveson

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.