Re^7: Introspecting function signatures

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.

Comment on Re^7: Introspecting function signatures Select or Download Code

Replies are listed 'Best First'.
Re^8: Introspecting function signatures by LanX (Saint) on Mar 06, 2021 at 22:14 UTC
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}	[reply] [d/l] [select]
Re^9: Introspecting function signatures by jcb (Parson) on Mar 08, 2021 at 01:58 UTC
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.	[reply]
Re^8: Introspecting function signatures by szabgab (Priest) on Mar 07, 2021 at 05:59 UTC
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.	[reply] [d/l]
Re^9: Introspecting function signatures by LanX (Saint) on Mar 07, 2021 at 13:48 UTC
you'll also have the benefit of putting repeated fixtures in the closure. compare this Pytest discussion about the resulting boilerplate https://stackoverflow.com/questions/63292928/add-pytest-fixtures-to-a-test-class-using-dependency-injection you might want to avoid importing their flows. :) Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply]
Re^10: Introspecting function signatures by szabgab (Priest) on Mar 07, 2021 at 14:14 UTC
I am not sure what closure are you talking about here, but the best would be if you could show a code snippet how you think it would be used in a test? And yes, it would be nice to avoid the linked problem.	[reply]
Re^11: Introspecting function signatures by LanX (Saint) on Mar 07, 2021 at 14:36 UTC
Re^12: Introspecting function signatures by szabgab (Priest) on Mar 07, 2021 at 21:13 UTC
Some notes below your chosen depth have not been shown here

Username:
Password:


No such thing as a small change
	PerlMonks

This is PerlMonks "Mobile"

edit