Is there a reason why they need to be available as parameters at all? These fixtures could just be global variables, couldn't they?

They could, but this way they are localized to the function, they go out of scope after the function is done and one test will not impact another test.

I would use local for that:

{
    local $tempdir = '/tmp/foo';
    test_someting();
}
[download]

Most likely you need to wrap all these test_something(...) function calls anyway with your code, and that's a good place to set up the localized test fixtures as well.

I'm wondering a bit how you plan to handle one such function calling another function. Should the fixtures be recreated or not?

sub test_someting2( $tempdir, $aValue ) {
    if( $^O !~ /mswin/i ) {
        test_someting("$tempdir/$aValue");
    } else {
        test_someting("$tempdir\\$aValue");
    };
}
[download]

You want to parse

sub test_someting($tempdir) {
    # do some tests
}
[download]

And because you see the (registered) keyword "tempdir" your test system is supposed to call this test with a prepared temporary directory?

ok(
    test_something( create_tempdir() ),
    "something",
)
[download]

Kind of a naming convention?

Did I get it right?

If yes, I could think of some alternative (and more perlish) ways to achieve this without needing to parse the signature.

PS: not sure why you call this "dependency injection" or do you plan testruns where the injected $tempdir is not a temporary dir? :)

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.

"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

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.