Scope Isolation and Direct Test Execution

Test scripts are now executed in the caller's scope, instead of in Pester's module scope.  This means that the only Pester functions and variables available to the SUT will be the ones that Pester exports, and that tests won't fail if the file happens to use variables that match the names of internal Pester parameters ($test, etc.)
Note:  Some of pester's own test scripts are intended to be able to access its internal implementation details, and a mechanism for executing these tests has also been added.  This syntax can also bee used to execute test code in the scope of another module, if that is useful.

    InModuleScope Pester {
        Describe "Description" {
            # etc
        }
    }

Test script files can now be executed directly, if desired.  However, doing so gives up most of the functionality offered by Invoke-Pester.  When executing a test file this way, you no longer get a summary of tests passed / failed, can't output to NUnit or use -Passthru, etc.

Mocking code has been revised to be aware of the scope of the code being tested.  Mock -ModuleName has been changed slightly; it now allows you to mock CALLS to any command from inside a module.  This overlaps slightly with the InModuleScope command; the following two constructs have the same effect:

    Mock -ModuleName TestModule InternalFunction { 'I am the mock.' }

    InModuleScope TestModule {
        Mock InternalFunction { 'I am the mock.' }
    }

The difference is that when using InModuleScope, you can execute internal module functions directly.  This can be used to perform unit tests on a module's implementation details, instead of only being able to access its public API.

Module mocks can now be used to mock a call to any command from inside a module, instead of only mocking a module's own internal functions.  For example:

    Mock -ModuleName TestModule Start-Sleep { 'Sleep is for the weak.' }