ScottHutchinson commented 3 years ago

There doesn't seem to be any test coverage of the Fixes.resolveNamespace function.

If I can figure out how to do it, I'll add some tests myself.

baronfel commented 3 years ago

There's a bunch of state that has to be set up just right to test codefixes in general, so I'll outline that process here for posterity:

Process overview

we'll be making a test that will:

contain a set of test FSX scripts or projects that contain the particular source files you want to test (ie a script with a missing namespace that you want to run against to verify the resolveNamespace codefix)
create an FSAC LSP server that's been pointed at that directory and initialized by reading those files and typechecking them
collect the diagnostics received for a particular file in question, to get any relevant diagnostics (since many of these codefixes are keyed by specific diagnostics)
use the collected diagnostics to create a TextDocumentCodeActionParams payload that you expect trigger the codefix
call the codefix function indirectly via the TextDocumentCodeAction member on the FsharpLspServer type (recommended)
perform assertions on the results of that call, for example the results of a resolveNamespace fix test would assert that a particular open <blah> edit was suggested by the server and that it was to be inserted as position .

details

test data

Code fix test data should probably go in a new subfolder of the test/FsAutoComplete.Tests.Lsp/TestCases directory. Inside that directory you can have any project or script file structure you think is relevant to your tests.

create lsp server keyed to your data

There's a bunch of setup here, but in general you'll want to use the serverInitialize function to start a server at some path with a particular configuration of settings. This can go about a billion different ways, all I can say is to check other tests for examples.

Collect diagnostics for a file

once you have a server, you'll want to call server.TextDocumentDidOpen to simulate an open of a file. This will trigger type checking. You can wait for typechecking of that file, and reporting of diagnostics on that file, by using the waitForParseResultsForFile helper function from the Helpers module of the tests project. Once you have those diagnostics, you can start making assertions on them

create the payload

once you have diagnostics, you can use them to create a payload to ask the server what code actions are available at a given position:

let context : CodeActionParams =
   { TextDocument = { Uri = Path.FilePathToUri scriptPath }
     Range = { Start = { Line = 3; Character = 13 }; End = {Line = 3; Character = 13} }
     Context = {
      Diagnostics = [| diags.[0] |]
    }
   }

This the important parts are:

the document to operate on
the position of the cursor when the request was invoked (count out the lines and columns in your sample file)
the diagnostic to use to provide additional context

call the codefix function

with this context, you can call server.TextDocumentCodeAction context and match on the results of the call. if you did everything right, the payload will have data that you can match on to do assertions

perform assertions

As a sample, something like the following could be used to check if the open was suggested for the System namespace when the user asked for code actions on the string TimeSpan in a script file. The exact line numbers might not match up exactly, but in general something similar to this would be used. Depending on the kinds of suggestions the codefix you want to test suggestions, your assertions might look different. Here I'm saying that open System should have been suggested at the beginning of the second line.

match server.TextDocumentCodeAction context |> Async.RunSynchronously with
| Ok (Some (TextDocumentCodeActionResult.CodeActions actions)) ->
  Expect.exists actions
   (function
    | { Kind = Some "fix"
        Edit = { DocumentChanges = Some [| {Edits = [| { NewText = "open System"; Range = { Start = {  Line = 2; Character = 0 }; End = { Line = 2; Character = 0 }} } |] }  |] } } -> true
    | _ -> false)
    "should have found a matching diagnostic"
| _ -> failwith "code actions should have returned actions for this file"

A working end-to-end test of this kind can be seen here