1. We should follow our guidance

throw "No Exception!"

2. We should not filter exceptions with catch [System.Management.Automation.MethodInvocationException]
   We should catch all exceptions and compare them with the expected one.

The same.

In fail test case the Invoke() will be raise CommandNotFoundException exception.
Also the test check nothing because Get-Process is always present by default.
With changing the limit to three cmdlets:

New-PSRoleCapabilityFile -Path $GoodRoleCapFile -VisibleCmdlets 'Get-Command','Get-Process','Clear-Host'

we could do something like:

    It "Verifies good role capability file" {

        try {
            New-PSSessionConfigurationFile -Path $PSSessionConfigFile -RoleDefinitions @{
                Administrators = @{ RoleCapabilityFiles = "$GoodRoleCapFile" }
            }

            $iss = [initialsessionstate]::CreateFromSessionConfigurationFile($PSSessionConfigFile, { $true })
            $ps = [powershell]::Create($iss)
            $result1 = $ps.AddCommand('Get-Command').Invoke()
            $result2 = $ps.AddCommand('Get-Command').AddParameter('Name', 'Clear-Host').Invoke()
            $result3 = $ps.AddCommand('Get-Command').AddParameter('Name', 'Get-Process').Invoke()
        } finally {
            if ($ps) { $ps.Dispose() }
        }
        $result1.Count | Should Be 3
        $result2.Name | Should Be "Clear-Host"
        $result3.Name | Should Be "Get-Process"
    }

We should not again raise an exception. It is enough to check the current exception. In other words the L53 is sufficient.

try  {  
           $iss = [initialsessionstate]::CreateFromSessionConfigurationFile($PSSessionConfigFile, { $true })  
           throw 'No Exception!'  
 }  
 catch  
 {  
     $_.Exception.InnerException.ErrorRecord.FullyQualifiedErrorId | Should Be 'CouldNotFindRoleCapabilityFile'  
 }  

It is not sufficient because L53 is invoked only if the correct exception is found. If it is not the expected exception then the test must fail.

I have to say that not filtering on the desired exception feels like an arbitrary and unneeded change. It did exactly what I intended and with less code.

Sorry, maybe I don't see nuances in this test.
My understanding is:

1. The tested code should call a particular exception CouldNotFindRoleCapabilityFile
2. We need to catch all exceptions, because we do not know whether this code caused the correct or incorrect exception.
3. We need to check that the exception is correct or incorrect - all by one Should Be:

$_.Exception.InnerException.ErrorRecord.FullyQualifiedErrorId | Should Be 'CouldNotFindRoleCapabilityFile'

Oh I see. Yes this will work. But if an incorrect exception is thrown then we will likely get a "null reference" exception when the test fails instead of seeing the actual thrown exception. But I guess this is Ok.

The cast may throw 😖 Maybe use the pattern as in the last test with Gettype()?

The same.

The pattern we can use for all test above too.
Only here GetType() call may raise a "null reference" exception.

        try
        {
            $ps.Invoke()
            throw 'No Exception!'
        }
        catch
        {
            if ($_.Exception.InnerException) {
                $exc_name = $_.Exception.InnerException.GetType().FullName 
            }
            $exc_name | Should Be 'System.Management.Automation.CommandNotFoundException'
        }

I notice windows specific paths (C:\\) are used in the code, and I assume the related functionalities are not supported on unix plats, but what would be the user experience? New-PSSessionConfigurationFile is exposed on unix plats, so will it throw a friendly error when running the following?

New-PSSessionConfigurationFile -Path $PSSessionConfigFile -RoleDefinitions @{
           Administrators = @{ RoleCapabilityFiles = "$RoleCapDirectory\NoFile.psrc" }
}

Remoting endpoint configuration is supported on Windows only, at least for now, hence the Windows only test restriction. This change follows the existing code as originally ported.

Do you mean this cmdlet shouldn't be exposed on Linux/OSX at all? I opened #3147 to track this usability issue.
The code change LGTM.

Yes, none of our remoting endpoint configuration works on Linux since it is specific to Windows/WinRM, and is not functional with OMI/WinRM AFAIK. I hope to create an RFC in the not too distant future that proposes how this might work on Linux, including JEA and hosting model.

Can you please make this issue more general since it involves more than just one cmdlet and is really about endpoint configuration on Linux.

Thanks for the clarification. I updated the issue to make it more general. Feel free to update further to make it more clear.