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.

"dependency injection" is how this is called in the case of pytest, maybe it is not a generic term

Well, I think Dependency Injection is a very well-known generic term, and heavily used in statically typed languages (e.g. C++, Java, C#) though it seems to be much less popular in dynamic languages, such as Perl and Python, as indicated here:

Dependency injection (DI) is regarded with suspicion in the Python world ... The standard way to do things is to declare our dependency implicitly by simply importing it, and then if we ever need to change it for tests, we can monkeypatch, as is Right and True in dynamic languages.

A reply to this SO question states that "A MonkeyPatch is a piece of Python code which extends or modifies other code at runtime (typically at startup)".

In frustration, I searched all of docs.pytest.org and the only reference I found to dependency injection was:

consider using pytest’s more powerful fixture mechanism which leverages the concept of dependency injection

So please put me out of my misery by pointing us at the pytest dependency injection documentation you saw.

BTW, I've happily used Dependency Injection for years in C++ (but not Perl). In C++, you define an interface argument to the class constructor, then, in the unit test, inject a mock object (an instance of a class inheriting from the interface class), while injecting an instance of the real class (also inheriting from the same interface class) in production code. ... Hmmmm, I see I liked it so much that I explicitly singled it out as "perhaps the most important design pattern in making code easier to test" at Effective Automated Testing.

Update: See this reply for a nice example of using Dependency Injection in Perl by chromatic.

Monkey Patching References

• Monkey patch (wikipedia)
• monkey patching (SO)
• code-maven
• Re: Help to override Spreadsheet/ParseXLSX.pm module by LanX
• Re^3: Retrieve Rendered Web Page Using WWW::Mechanize::Chrome by Corion
• Re: Dealing with package version numbers when monkey-punching by tobyink
• Safer monkey-patching by tobyink
• monkey patching an entire module by perl5ever
• Monkey patching all subs with a basic 'starting subname' message by anonymonk
• Re: How to get function's name inside of CODE attribute by chromatic

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}

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

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

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/;    
  #...

}
[download]

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}

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();
    # ...
}
[download]

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.