clean up about files

en-US/about_Mocking.help.txt

@@ -0,0 +1,79 @@
+TOPIC
+	Mocking
+
+SYNOPSIS
+	Pester provides a set of Mocking functions making it easy to fake dependencies 
+	and also to verify behavior. Using these mocking functions can allow you to 
+	"shim" a data layer or mock other complex functions that already have their 
+	own tests.
+
+DESCRIPTION
+	With the set of Mocking functions that Pester exposes, one can:
+
+	- Mock the behavior of ANY powershell command.
+	- Verify that specific commands were (or were not) called.
+	- Verify the number of times a command was called with a set of specified 
+	  parameters.
+
+MOCKING FUNCTIONS
+	See Get-Help for any of the below functions for more detailed information.
+
+	Mock
+		Mocks the behavior of an existing command with an alternate 
+		implementation.
+
+	Assert-VerifiableMocks
+		Checks if any Verifiable Mock has not been invoked. If so, this will 
+		throw an exception.
+
+	Assert-MockCalled
+		Checks if a Mocked command has been called a certain number of times 
+		and throws an exception if it has not.
+
+EXAMPLE
+	function BuildIfChanged {
+		$thisVersion=Get-Version
+		$nextVersion=Get-NextVersion
+		if($thisVersion -ne $nextVersion) {Build $nextVersion}
+		return $nextVersion
+	}
+
+    $here = Split-Path -Parent $MyInvocation.MyCommand.Path
+    $sut = (Split-Path -Leaf $MyInvocation.MyCommand.Path).Replace(".Tests.", ".")
+    . "$here\$sut"
+
+    Describe "BuildIfChanged" {
+    	Context "Wnen there are Changes" {
+    		Mock Get-Version {return 1.1}
+    		Mock Get-NextVersion {return 1.2}
+    		Mock Build {} -Verifiable -ParameterFilter {$version -eq 1.2}
+
+    		$result = BuildIfChanged
+
+	        It "Builds the next version" {
+	            Assert-VerifiableMocks
+	        }
+	        It "returns the next version number" {
+	            $result.Should.Be(1.2)
+	        }
+        }
+    	Context "Wnen there are no Changes" {
+    		Mock Get-Version -MockWith {return 1.1}
+    		Mock Get-NextVersion -MockWith {return 1.1}
+    		Mock Build -MockWith {}
+
+    		$result = BuildIfChanged
+
+	        It "Should not build the next version" {
+	            Assert-MockCalled Build -Times 0 -ParameterFilter{$version -eq 1.1}
+	        }
+        }
+    }
+
+SEE ALSO
+	Mock
+	Assert-VerifiableMocks
+	Assert-MockCalled
+	Describe
+	Context
+	It

en-US/about_Pester.help.txt

@@ -5,14 +5,24 @@ SYNOPSIS
 	Pester is a BDD based test runner for PowerShell.
 
 DESCRIPTION
-	Pester provides a framework for running Unit Tests to execute and validate Powershell commands. Pester follows a file naming convention for naming tests to be discovered by pester at test time and a simple set of functions that expose a Testing DSL for isolating, running, evaluating and reporting the results of Powershell commands.
+	Pester provides a framework for running Unit Tests to execute and validate 
+	Powershell commands. Pester follows a file naming convention for naming 
+	tests to be discovered by pester at test time and a simple set of 
+	functions that expose a Testing DSL for isolating, running, evaluating and 
+	reporting the results of Powershell commands.
 
-	Pester tests can execute any command or script that is accesible to a pester test file. This can include functions, Cmdlets, Modules and scripts. Pester can be run in ad hoc style in a console or it can be integrated into the Build scripts of a Continuous Integration system.
+	Pester tests can execute any command or script that is accesible to a 
+	pester test file. This can include functions, Cmdlets, Modules and scripts. 
+	Pester can be run in ad hoc style in a console or it can be integrated into 
+	the Build scripts of a Continuous Integration system.
 
-	Pester also contains a powerful set of Mocking Functions that allow tests to mimic and mock the functionality of any command inside of a piece of powershell code being tested. See about_Mocking.
+	Pester also contains a powerful set of Mocking Functions that allow tests to 
+	mimic and mock the functionality of any command inside of a piece of 
+	powershell code being tested. See about_Mocking.
 
 CREATING PESTER TEST WITH
-	To start using Pester, You may use the Add-Fixture function to scaffold both a new implemntation function and a test function.
+	To start using Pester, You may use the Add-Fixture function to scaffold both 
+	a new implemntation function and a test function.
 
 	C:\PS>New-Fixture deploy Clean
 
@@ -22,10 +32,10 @@ CREATING PESTER TEST WITH
 
 	}
 
-	./deploy/clean.Tests.ps1
-	$here = Split-Path -Parent $MyInvocation.MyCommand.Path
-	    $sut = (Split-Path -Leaf $MyInvocation.MyCommand.Path).Replace(".Tests.", ".")
-	    . "$here\$sut"
+    ./deploy/clean.Tests.ps1
+    $here = Split-Path -Parent $MyInvocation.MyCommand.Path
+    $sut = (Split-Path -Leaf $MyInvocation.MyCommand.Path).Replace(".Tests.", ".")
+    . "$here\$sut"
 
     Describe "clean" {
 
@@ -34,28 +44,88 @@ CREATING PESTER TEST WITH
         }
     }
 
-    Now you have a skeleton of a clean function with a failing test. Pester considers all files containing *.Tests.* to be a test file (see Invoke-Pester) and by default it will look for these files and run all Describe blocks inside the file (See Describe). The Describe block can contain several behavior validations expressed in It blocks (see It). Each It block should test one thing and throw an exception if the test fails. Pester will consider any It block that throws an exception to be a failed test. Pester provides a set of extensions that can perform various comparisons between the values emited or altered by a test and an expected value (see about_Should). 
+    Now you have a skeleton of a clean function with a failing test. Pester 
+    considers all files containing *.Tests.* to be a test file (see 
+    nvoke-Pester) and by default it will look for these files and run all 
+    Describe blocks inside the file (See Describe). The Describe block can 
+    contain several behavior validations expressed in It blocks (see It). 
+    Each It block should test one thing and throw an exception if the test 
+    fails. Pester will consider any It block that throws an exception to be a 
+    failed test. Pester provides a set of extensions that can perform various 
+    comparisons between the values emited or altered by a test and an expected 
+    value (see about_Should). 
 
 RUNNNING A PESTER TEST
-	Once you have some logic that you are ready to test, use the Invoke-Pester command to run the tests. You can zero in on just one test (Describe block) or an entire tree of directories.
+	Once you have some logic that you are ready to test, use the Invoke-Pester 
+	command to run the tests. You can zero in on just one test (Describe block) 
+	or an entire tree of directories.
+
+	function BuildIfChanged {
+		$thisVersion=Get-Version
+		$nextVersion=Get-NextVersion
+		if($thisVersion -ne $nextVersion) {Build $nextVersion}
+		return $nextVersion
+	}
+
+	$here = Split-Path -Parent $MyInvocation.MyCommand.Path
+    $sut = (Split-Path -Leaf $MyInvocation.MyCommand.Path).Replace(".Tests.", ".")
+    . "$here\$sut"
+
+    Describe "BuildIfChanged" {
+    	Context "Wnen there are Changes" {
+    		Mock Get-Version {return 1.1}
+    		Mock Get-NextVersion {return 1.2}
+    		Mock Build {} -Verifiable -ParameterFilter {$version -eq 1.2}
+
+    		$result = BuildIfChanged
+
+	        It "Builds the next version" {
+	            Assert-VerifiableMocks
+	        }
+	        It "returns the next version number" {
+	            $result.Should.Be(1.2)
+	        }
+        }
+    	Context "Wnen there are no Changes" {
+    		Mock Get-Version -MockWith {return 1.1}
+    		Mock Get-NextVersion -MockWith {return 1.1}
+    		Mock Build {}
+
+    		$result = BuildIfChanged
+
+	        It "Should not build the next version" {
+	            Assert-MockCalled Build -Times 0 -ParameterFilter{$version -eq 1.1}
+	        }
+        }
+    }
 
 	C:\PS>Invoke-Pester
 
-	This will run all tests recursively from the current directory downwards and print a report of all failing and passing tests to the console.
+	This will run all tests recursively from the current directory downwards 
+	and print a report of all failing and passing tests to the console.
 
 PESTER AND CONTINUOUS INTEGRATION
-	Pester integrates well with almost any build automation solution. You could create a MSBuild target that calls Pester's convenience Batch file:
+	Pester integrates well with almost any build automation solution. You 
+	could create a MSBuild target that calls Pester's convenience Batch file:
 
 	<Target Name="Tests">
 	<Exec Command="cmd /c $(baseDir)pester\bin\pester.bat" />
 	</Target>
 
-	This will start a powershell session, import the Pester Module and call invoke pester within the current directory. If any test fails, it will return an exit code equal to the number of failed tests and all test results will be saved to Test.xml using NUnit's Schema allowing you to plug these results nicely into most Build systems like CruiseControl, TeamCity, TFS or Jenkins.
-
+	This will start a powershell session, import the Pester Module and call 
+	invoke pester within the current directory. If any test fails, it will 
+	return an exit code equal to the number of failed tests and all test 
+	results will be saved to Test.xml using NUnit's Schema allowing you to 
+	plug these results nicely into most Build systems like CruiseControl, 
+	TeamCity, TFS or Jenkins.
+
 OTHER EXAMPLES
-	Pester's own tests. See all files in the Pester Functions folder containing *.Tests.*
+	Pester's own tests. See all files in the Pester Functions folder 
+	containing *.Tests.*
 
-	Chocolatey tests. Chocolatey is a popular powershell based Windowspackage management system. It uses Pester tests to validate its own functionality.
+	Chocolatey tests. Chocolatey is a popular powershell based Windows 
+	package management system. It uses Pester tests to validate its own 
+	functionality.
 
 SEE ALSO
 	about_Mocking

en-US/about_TestDrive.help.txt

@@ -2,10 +2,17 @@ TOPIC
 	TestDrive
 
 SYNOPSIS
-	A PSDrive for file activity limited to the scope of a singe Describe or Context block.
+	A PSDrive for file activity limited to the scope of a singe Describe or 
+	Context block.
 
 DESCRIPTION	
-	A test may need to work with file operations and validate certain tyes of file activities. It is usually desirable not to perform file activity tests that will produce side effects outside of an individual test. Pester creates a PSDrive inside the user's temporary drive that is accesible via a names PSDrive TestDrive:. Pester will remove this drive afterthe test completes. You may use this drive to isolate the file operations of your test to a temporary store.
+	A test may need to work with file operations and validate certain tyes of 
+	file activities. It is usually desirable not to perform file activity tests 
+	that will produce side effects outside of an individual test. Pester 
+	creates a PSDrive inside the user's temporary drive that is accesible via a 
+	names PSDrive TestDrive:. Pester will remove this drive afterthe test 
+	completes. You may use this drive to isolate the file operations of your 
+	test to a temporary store.
 
 EXAMPLE
 	function Add-Footer($path, $footer) {
@@ -23,9 +30,11 @@ EXAMPLE
 	    }
 	}
 
-	When this test completes, the contents of the TestDrive PSDrive will be removed.
+	When this test completes, the contents of the TestDrive PSDrive will 
+	be removed.
 
 SEE ALSO
+	Context
 	Describe
 	It
 	about_Should

en-US/about_should.help.txt

@@ -1,29 +1,44 @@
-NAME
+TOPIC
 	Should
 
 SYNOPSIS
-	Provides assertion convenience methods for comapring objects and throwing test failures when test expectations fail.
+	Provides assertion convenience methods for comapring objects and throwing 
+	test failures when test expectations fail.
 
 DESCRIPTION
-	Should is an Extension of System.Object and can be used as a native type inside Describe blocks. The various Should member methods can be invoked directly from an object being compared. It is typically used in individual It blocks to verify the results of an expectation. The Should method is typically called from the "actual" object being compared and takes the "expected" object as a parameter. Should includes several members that perform various comparisons of objects and will throw a PesterFailure when the objects do not evaluate to be comparable.
+	Should is an Extension of System.Object and can be used as a native type 
+	inside Describe blocks. The various Should member methods can be invoked 
+	directly from an object being compared. It is typically used in individual 
+	It blocks to verify the results of an expectation. The Should method is 
+	typically called from the "actual" object being compared and takes the 
+	"expected" object as a parameter. Should includes several members that 
+	perform various comparisons of objects and will throw a PesterFailure when 
+	the objects do not evaluate to be comparable.
 
 SHOULD MEMBERS
 
 	Be
-		Compares one object with another for equality and throws if the two objects are not the same.
+		Compares one object with another for equality and throws if the two 
+		objects are not the same.
 
 		C:\PS>$actual="actual value"
 		C:\PS>$actual.Should.Be("actual value") #Nothing happens
 		C:\PS>$actual.Should.Be("not actual value") #A Pester Failure is thrown
 
 	Have_Count_Of
-		Intended for comparing IEnumerables for the number of elements. However, if both objects being compared do not implement IEnumerable then the comparison will pass since both objects will be treated as though they have a count of 1. As of Powershell version 3, a $null object compared to a non null object will fail. They will pass in version 2.0.
+		Intended for comparing IEnumerables for the number of elements. However, 
+		if both objects being compared do not implement IEnumerable then the 
+		comparison will pass since both objects will be treated as though they 
+		have a count of 1. As of Powershell version 3, a $null object compared 
+		to a non null object will fail. They will pass in version 2.0.
 
 		C:\PS>$actual=@(1,2,3)
 		C:\PS>$actual.Should.Have_Count_Of(@(3,2)) #Will fail
 
 	Exist
-		Does not perform any comparison but checks if the object calling Exist is presnt in a PS Provider. The object must have valid path syntax. It essentially must pass a Test-Path call.
+		Does not perform any comparison but checks if the object calling Exist 
+		is presnt in a PS Provider. The object must have valid path syntax. It 
+		essentially must pass a Test-Path call.
 
 		C:\PS>$actual=(Dir . )[0].FullName
 		C:\PS>Remove-Item $actual