On 08/05/2014 03:28 PM, Matthew Musgrove wrote:
I have a module that I've used for a while now. It only mocks Net::Ping's
ping method; however, it might be useful to extend it to support more of
the methods in the future.
Currently it is named Mock::Net::Ping. Should I stick with this name or
change it? If you think that I should change it, what name would you
recommend?

Doing a cursory search on CPAN, it seems that the work "Mock" appears at the beginning, in the middle, and/or at the end of multi-word module names. So, "Mock::Net::Ping" is not unreasonable. It might help if you posted the module/ replied with a URL and/or cut and pasted the POD into a reply.


Sorry for the tangent, but thank you for helping me to remember an idea -- mocking analogous to Log::Log4perl. If we can figure this out, it might affect your module.


I'm interested in mocking Perl primitives, non-OO/ imported module procedures, and OO module methods, and would be interested in finding a design pattern/ module that allows me to selectively enable mocking without making changes to the module in question, or any other code that uses the module in question -- e.g. the top-level program provides a command-line option, reads the environment, reads a configuration file, makes function calls, etc., and enables/ disables mocking as desired. Ideally, the module in question would "have stealth mocking"/ be "mocking enabled", and mocking would be re-configurable at run time.


Test::Mock::Simple seems to provide external mocking, is OO only, and provides a TEST_MOCK_SIMPLE_DISABLE environment variable:


http://search.cpan.org/~tank/Test-Mock-Simple-0.04/lib/Test/Mock/Simple.pm


Test::Mock::Guard seems to provide external mocking with lexical scope and is OO only:


http://search.cpan.org/~xaicron/Test-Mock-Guard-0.10/lib/Test/Mock/Guard.pm


Test::Mock::Class (and related) is a Moose module that might work, but I don't grok or use Moose (probably because I haven't read [1]:


http://search.cpan.org/~dexter/Test-Mock-Class-0.0303/lib/Test/Mock/Class.pm


Comments and suggestions are welcome.


David


References:

[1] Gregor Kiczales, et al, 1991, "The Art of the Metaobject Protocol", http://mitpress.mit.edu/books/art-metaobject-protocol .

Reply via email to