This idea of creating a "my" private variable as a sub ref to try to make a totally private function is a non-Perl idea, and not a good one. Perl assumes that you will conform to the interface spec. Or override it when you think it is necessary and proper.

If you make sub privateFunction{} and do not export the name "privateFunction" then anyone following the interface will not be able to call it.

If I know your module name and name of this sub, then even if the sub privateFunction() is not exported, I can call it with the fully qualified name YourModuleName::privateFunction();. Perl module I/F's keep "honest folks honest", but is possible to do "something not intended". Sometimes that's good and sometimes that bad.

In Perl as in C,etc., there are various naming conventions for Private vs Public functions. You can put _, underscore for a private func as a clue that this is not intended for it to be called outside the I/F, but it still can be.

There also appears to be a logical inconsistency in your test strategy. If this function is private, then NO external program should call it, including your test program. There should be a module test routine that tests that module(that test routine is part of the module). Your test program calls this test function, not in the private guts of the module itself. Your test function remains stable even in light of massive implementation changes within the module.

One easy technique for testing is to make a standard sub in each module say "sub test()" and don't export that name. To test, call YourModuleName::test();