enable/disable warnings for non-allowable modules

[BryanDonovan]

Not sure if this is the best way to do this, but this fork provides a way to enable/disable warning messages for non-allowable modules when they are loaded. Maybe there's a better way to deal with this, but in our application we get about 25 warning messages each time a test is run, most of which are modules like 'mysql' and 'util'.

-Bryan

[mfncooper]

A few questions, if you don't mind, to clarify the use case:

1. Are you using Mockery for functional / integration tests, rather than unit tests? I was primarily targeting unit tests, which is why the warnings are there. For true unit tests, I want to know about any "violation" of the unit; that is, any time the code in my unit (i.e. module under test) reaches out to some other module that isn't being mocked. However, I can see that, for functional or integration testing, this would be less of a concern.
2. Should I assume that you don't want to track the specific modules in that list of 25, and that it's not important to you if that list changes over time? I ask in case an easier way to specify a list of modules would be useful, rather than just saying "any". I get that 25 separate calls to registerAllowable would be "noisy".
3. Other ways of addressing your issue might be a means of simply turning off the "allowable" feature, or accepting "*" as a module value for registerAllowable. The effect would be the same, but the exposed semantic slightly different. I'll note that the "allowable" feature is really all about the warning, so having a module that isn't allowed and also doesn't warn doesn't really fit that.

I'd like to hear your thoughts before I decide how to proceed.

[BryanDonovan]

Sorry for the delay. I replied via email but it didn't go through I guess.

I suppose in a sense they are integration tests, but at a 'model' level. I agree in principle with mocking out all external dependencies, so I totally understand why you're doing that. It's just that I'd have way more code dedicated to mocking than dedicated to testing in our application, which is relatively complex, so I tend to mock only the things that are difficult to set up via fixtures, and which aren't difficult to mock (which is now much easier due to Mockery).

I'm happy with any of the solutions you're proposing though.

One thing that's painful with registering the allowables is when the relative paths are different for the same module, such as:

WARNING: loading non-allowed module: ./errors
WARNING: loading non-allowed module: ../../../core/api/errors