Added mocking support for internal module methods, aliases, applications, filters, etc

[skataben]

Added mocking support for:

• internal module methods
• alias commands
• application commands
• filter commands

Added partial mocking support for:

• fully-qualified command names (fully qualified cmdlet invocations are not supported)

• external script commands
  The only supported scenarios are when the script is invoked using one of the following methods:

  scriptName.ps1

  & scriptName.ps1

  . scriptName.ps1

Added corresponding unit tests.

[rafd123]

👍 Yes please!

[nohwnd]

@rafd123 Yes please, because of the module support? I am working on providing real support for module testing. Could we get in touch and discuss what exactly you need and do some testing?

[rafd123]

@nohwnd My vote was primarily for the ability to mock out private module members without resorting to this or forcing module authors into implementing their modules as a series of .ps1 files that ultimately get dot-sourced into the main module.

This pull request seemed to fit the bill and has worked for my purposes. The changes seem appropriate; if they don't meet a certain standard, I'd love to know why from an educational point of view.

In either case, I'd love to see this functionality make it into Pester-proper one way or another.

[nohwnd]

To be frank this is not merged because it is too big change and I (or some other owner) simply did not have the time to test it and merge it. Also I for some reason lived under the impression that the module support does not work the way it should. I am gonna re-test this now.

[nohwnd]

On first test it seems to work ok. Awesome! Why I did not see this before? Edit: This is pure gold!

[nohwnd]

@rafd123 Forgot to tag you in my responses. By "internal module members you mean functions? Or did you implement a way to mock internal module variables also?

[nohwnd]

@skataben is the way you "hook" the module your invention?

[nohwnd]

@skataben I got rid of the quote changes because they made the PR hard to follow and are mostly style preference and committed the changes as 062b02b. If there were any quote changes that made the code easier to read please create another pull request for them. Awesome work, thank you very much!

[skataben]

It might be more of a "discovery" than an invention, but if your asking if this work my own vs copy/pasted from somewhere else, it is my own.

[nohwnd]

@skataben In that case are officially a genius :)

[skataben]

Wrt to the quote changes, it is considered a "best practice" by many, myself included, to use literal strings (single quotes) vs expandable strings (double quotes) when possible. In my editor, I have a shortcut key that "auto-cleans" my files before I publish which, among other things, converts unnecessary expandable strings to literal ones. FYI, it gives the parser less work to perform (although the difference is admittedly negligible). IMHO, this goes beyond the realm of personal preferences into the realm of best practice, although I'll concede it is borderline.

[nohwnd]

@skataben I think we already discussed this here somewhere. If the change brings more than just trying to comply with one (pretty controversial) best practice then I am all in. But make it a clearly marked separate PR. The changes in this PR were big enough without all the "style" changes.

[rafd123]

@nohwnd To answer your question a few comments back: yes, I meant "internal module functions."

Mocking out variables seems less compelling than functions in general (let alone for modules) since one can always mock out the function depending on the variable. In a pinch, one can modify a module's "internal" variable by doing so within the module's closure. Example:

& $moduleUnderTest { $SomeInternalVariable = 'foo' }

FWIW, @skataben , I agree with you regarding the use of string literals to prevent accidental variable/expression expansion.

That said, I tend to agree with @nohwnd that it would have been nice to at least have those changes in a separate commit in the interest of keeping the commits well-factored...otherwise, it's kinda like throwing a smoke bomb into the commit. @nohwnd indicated that it was a large commit, but in reality the change was fairly scoped (no pun intended) once you took away the string-literal changes; probably would have expedited the PR. My 2 cents worth.

[rafd123]

Oh...and nice work, @skataben!! You made my life a little easier; much appreciated!! 😃

[nohwnd]

@rafd123 Once I saw how @skataben does the function mocking I realized how to do variable mocking. I was just asking if you expanded on it and already implemented it. :)

& $moduleUnderTest { $SomeInternalVariable = 'foo' }

This definitely needs some wrapping to respect the Pester mocking scopes/rules. I was thinking about -Variable switch for the Mock command. What do you think?

Mock internal 10 -ModuleName Test -Variable

or maybe keeping the ScriptBlock? Do you see any use case for that?

Mock internal {$internal-10} -ModuleName Test -Variable

Having both would be best right?

[rafd123]

I haven't had a need for it, but that'd be cool. Agreed that both value and ScriptBlock variants would be nice,