Add simple integration test, with an LSP client PowerShell module

[rjmholt]

I've written a small named-pipe-based LSP client in PowerShell, partly to understand PSES better and partly to provide an automated way for us to determine if PSES is loading and working properly with PowerShell.

There are two tests with this now:

• A startup/initialize/response message where we start the process, send an initialize message and check the response
• A shutdown message test, where we check the process understands a shutdown notification

[TylerLeonhardt]

These tests saved us 🎉

[rjmholt]

It works again!

[TylerLeonhardt]

I don't know if this is the right approach. Maybe it should be 2 Context's:

1. "Message handling"
2. "Startup and shutdown"

So the tests would be structured like this:

Describe "Loading and running PowerShellEditorServices" {
    BeforeAll {
        Import-Module -Force "$PSScriptRoot/../../module/PowerShellEditorServices"
        Import-Module -Force "$PSScriptRoot/../../tools/PsesPsClient/out/PsesPsClient"
        Import-Module -Force "$PSScriptRoot/../../tools/PsesLogAnalyzer"

        $logIdx = 0
    }
    Context "Startup and shutdown" {
        It "Can start up and shutdown" {
            # Start up
            $psesServer = Start-PsesServer
            $client = Connect-PsesServer -PipeName $psesServer.SessionDetails.languageServicePipeName

            # Shutdown
            $request = Send-LspShutdownRequest -Client $client
            $response = Get-LspResponse -Client $client -Id $request.Id
            $response.Id | Should -BeExactly $request.Id
            $response.Result | Should -BeNull
            # TODO: The server seems to stay up waiting for the debug connection
            # $psesServer.PsesProcess.HasExited | Should -BeTrue
           
            try
            {
                $psesServer.PsesProcess.Kill()
            }
            finally
            {
                try
                {
                    $psesServer.PsesProcess.Dispose()
                }
                finally
                {
                    $client.Dispose()
                }
            }

            ReportLogErrors -LogPath $psesServer.LogPath -FromIndex ([ref]$logIdx)
        }
    }

    Context "LSP messages" {
        BeforeAll {
            # Start up
            $psesServer = Start-PsesServer
            $client = Connect-PsesServer -PipeName $psesServer.SessionDetails.languageServicePipeName
        }
        AfterAll {
            try
            {
                $psesServer.PsesProcess.Kill()
            }
            finally
            {
                try
                {
                    $psesServer.PsesProcess.Dispose()
                }
                finally
                {
                    $client.Dispose()
                }
            }
        }
        It "Can send initialize request" {
            $request = Send-LspInitializeRequest -Client $client
            $response = Get-LspResponse -Client $client -Id $request.Id
            $response.Id | Should -BeExactly $request.Id

            ReportLogErrors -LogPath $psesServer.LogPath -FromIndex ([ref]$logIdx)
        }
        #
        # As time goes on we add more It's here for the other messages
        #
    }
}

[TylerLeonhardt]

That way the order doesn't matter and we can easily add new tests for other messages.

For the future:
I think the Send-LspInitializeRequest will actually probably need to be moved to the BeforeAll eventually once we add other messages that depend on that one having gone through.

We'll get there. Gotta figure out which messages depend on what and align the tests as much as possible to that back and forth.

[rjmholt]

Yeah I don't think there's any particularly obvious approach available at the moment. I think given that we're not planning impending development on this module that we should merge what we have since it works and is less code and then continue as is.

[TylerLeonhardt]

Fair

[rjmholt]

Definitely don't disagree with you though -- "unit" testing is very bad at sequential logic with dependent states.

I think we should refactor as you say, but will defer that to another PR.

[TylerLeonhardt]

LGTM