This is PerlMonks "Mobile"

Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  


in reply to Re^5: Introspecting function signatures
in thread Introspecting function signatures

Yes. "dependency injection" is how this is called in the case of pytest, maybe it is not a generic term. You could create your own "fixture" and then you or others could set its name as a parameter.

I put together an example of creating and registering a fixture and then also use that fixture.

I would love to see your suggestion for more Perlish way.

Replies are listed 'Best First'.
Re^7: Introspecting function signatures (Dependency Injection and Monkey Patching)
by eyepopslikeamosquito (Archbishop) on Mar 07, 2021 at 07:02 UTC
      I think this niche is mainly filled by conditional use/imports in dynamic languages (see if )

      Monkey patching is only one other possibility here (that's replacing a sub/method at runtime), we also have eval and BEGIN blocks ... etc.

      > In frustration, I searched all

      that's "terminology injection" (aka die "brain overflow" ;-)

      Like all these Java OO "design patterns" which are superfluous in Perl.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery

        that's "terminology injection" (aka die "brain overflow" ;-)
        Ha ha, I noticed a mind-boggling number of different ways to do this type of stuff in Perl. For example, chromatic refers here to a modernperlbooks article which gives the illustrative example below:

        At its core, dependency injection is a formalization of the design principle "Don't hard-code your dependencies." Consider the code:

        sub fetch { my ($self, $uri) = @_; my $ua = LWP::UserAgent->new; my $resp = $ua->get( $uri ); ... }

        That's not bad code by any means, but it's a little too specific and a little less generic due to the presence of the literal string LWP::UserAgent. That might be fine for your application, but that hard-coding introduces a coupling that can work against other uses of this code. Imagine testing this code, for example. While you could use Test::MockObject to intercept calls to LWP::UserAgent's constructor, that approach manipulates Perl symbol tables to work around a hard coded dependency.

        An alternate approach uses a touch of indirection to allow for greater genericity:

        use Moose; has 'ua', is => 'ro', default => sub { LWP::UserAgent->new }; sub fetch { my ($self, $uri) = @_; my $ua = $self->ua; my $resp = $ua->get( $uri ); ... }
        Now the choice of user agent is up to the code which constructs this object. If it provides a ua to the constructor, fetch() will use that. Otherwise, the default behavior is to use LWP::UserAgent as before.

        Lots of stuff on CPAN too:

        As usual, the hard part is knowing which is good and which is crap. Please let us know of other cool CPAN offerings I've overlooked.

Re^7: Introspecting function signatures
by jcb (Parson) on Mar 06, 2021 at 21:51 UTC

    My suggestion is to just have the test routine call back into the framework:

    sub test_something { my $tempdir = create_tempdir(); # ... }

    Then the framework only needs to iterate over the package stash and call all test_* functions. Which leads to a "is this a good idea?" question — this style of testing means that the test routines are included with the main code and will have to be compiled every time the module is loaded. Python reduces this overhead by automatically using its form of B::Bytecode/ByteLoader but Perl does not do that, so this style will add some incremental overhead to all use of any module using it. The traditional Perl style of separate test scripts completely avoids this last problem.

      Not sure what Python is implementing with that pattern, but I know it doesn't have block-scope, OTOH nesting functions is easier there.

      So many things which are just blocks in Perl become named functions there, even lamda is useless for that.

      But no need to copy their limitations.

      My suggestion would be to apply attributes or explicit use

      sub :test something { my :TEMPDIR $tempdir = shift; # or my :FIXTURE $tempdir = shift; # or use fixture qw/$tempdir/; #... }

      This offers plenty of possibilities at compile time and is more flexible than Python's approach.

      edit

      and I'd certainly put test-subs into their own package, if they lived in the same file.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery

        I'd certainly put test-subs into their own package, if they lived in the same file.

        That does not reduce the overhead problem I mentioned — the test-subs will still be compiled every time the module containing them is loaded. Only putting the tests into a separate file solves that problem.

      This can indeed be a good solution. Given that perl will reliably call DESTROY when an object goes out of scope, this could ensure that whatever the object holds will be cleaned up. It is a bit more code to write as we need to call the function, but might be reasonable.
      sub test_something { my $tempdir = create_tempdir(); # ... }

      I don't know where the idea came from that in Python people include the tests in the main code. Maybe that was the case 10 years ago, but these days the standard is that tests are in separate files called test_SOMETHING.py.