How are you handling thoseinternally declared exceptions?

Dec 30, 2009 at 8:56 PM

After running into (and voting for) the same issue with ParamterBindingValidationException as described at both:

This is the solution I'm working with now:

In PSUnit.Run.ps1

      $FunctionOutput = Execute-Test $_
	  if ( $ExpectedExceptionTypeName -ne "ExpectedException Parameter is not defined in function $($CurrentFunction.Name)") {
	  	throw (New-Object System.InvalidOperationException "Failed to throw an exception!`nExpected `"$ExpectedExceptionTypeName`"" )
      Report-TestResult -Test $CurrentFunction -Result "PASS"
      $ActualExceptionTypeName = $_.Exception.GetType().FullName
      Write-Debug "PSUnit.Run.ps1: Execution of `"$CurrentFunction`" caused following Exception `"$($_.Exception.GetType().FullName)`""
      Write-Debug "PSUnit.Run.ps1: ExpectedException = `"$ExpectedExceptionTypeName`""
      if ( ($ActualExceptionTypeName -eq $ExpectedExceptionTypeName) -or
	  	( ($ExpectedExceptionTypeName -eq ($_.Exception.GetType()).UnderlyingSystemType.BaseType.FullName) -and
		([regex]::IsMatch($CurrentFunction.Definition, "Actual: .*$ActualExceptionTypeName") ) ) )
        Report-TestResult -Test $CurrentFunction -Result "PASS"
        Report-TestResult -Test $CurrentFunction -Result "FAIL" -Reason $_

Then, since I didn't see anywhere in PSUnit that the default value for a parameter was being used, we can make use of the the value like so:
function Test.TestPathParameters_Invalid_ShouldThrow(
	[switch] $Category_Parameters,
	[System.Management.Automation.ParameterBindingException] $ExpectedException `
		= "Actual: System.Management.Automation.ParameterBindingValidationException") {

	$Actual = testPathParameter -Path $TMP_TESTFILES_PATH\invalid\

So, by having an advanced function with validation on the -Path parameter the test can properly pass and we can be relatively positive that the exception thrown is the correct one.

I'd be interested in hearing any feedback on this idea.




Dec 30, 2009 at 9:54 PM

Hi Thell,

I like your workaround. I initially considered some other approaches as well, but decided that I didn't want to sacrify the simplicity of the design for some unusual edgecases. I actually changed some of my advanced functions by splitting them in to a parameter validation wrapper function and the actual function. The parameter validation wrapper would throw a public execption object in the catch clause in the case of the ParameterValidation exceptions. I added basically one layer of indirection to make the validation testable without having to compromise too much.

I will do consider your suggestion for the next round of changes.

Thanks for your feedback,


Jun 27, 2012 at 8:11 AM

any solution about it ?