Reduce code reuse in CompletionSpec.hs

[cronokirby]

Having modified this file a few times recently, I've noticed that there's quite a bit of code repetition in how we execute tests.

Often times all we want to do is insert some text at any blank location and see what completion we get.
Or we just want to edit a specific location and again, check completions. The machinery to setup a session and open the same file is repeated all throughout the various tests.

I think it would be a good idea to address this by either creating reusable functions for testing completions in the module, or perhaps even creating an even higher level interface over test that edit a file, so that we could reuse it across all of the editing tests.

Would love to gather thoughts about this :)

[lorenzo]

I think it makes sense to consolidate. Ideally we should have some sort of DSL to write the tests instead of going down to the protocol level messages and lifting things to IO.

Can you maybe put together a proposal on how you would consolidate the repetition in that module?

[cronokirby]

Here are some of my thoughts on the current issues and potential solutions:

Current Problems

In every test we want to see what completions we get in a certain editing state, but we instead
need to specify the minute textual operations to an existing file.

Problems with this as I see it:

• Every test depends on the implicit state of an external file, and it isn't clear what state that file is in
  when we ask for a completion for the test.
• We need to specify the exact text manipulations instead of just getting the completion for a certain state.
• We reuse a lot of boilerplate between tests because the actual difference between them is at a much higher level.

Possible solutions

• Have a higher level DSL for these tests

When testing, we don't care where the new text is inserted, or how, we simply care what completion we get for a piece of text. We'd need some kind of way to simply state that we want to add a new piece of text, and see what gets completed. This functionality should take care of applying the necessary setting up of an editing session, as well as applying the textual edit, and then giving us the completion.

• Minimise dependencies on existing text in the file

Instead of partially editing a line, instead the way the test is implemented should completely describe the state of the editing that the completion depends on. This would make it much clearer what exactly the completion is acting on. This would help implement the above point as well.

I think that this should be more or less a matter of implementing a handful of functions that abstract over the repeated work. something like

completeNewLine :: Text -> IO CompletionItem

Seems like the uniting thread between the various tests in this module.

Interested in gathering more opinions on this.

[alanz]

@bubba this sounds like something that could be done through and update to lsp-test.

[lukel97]

The DSL sounds like the way to go. I also think it might also be worthwhile creating a function that can kick off a session that automatically opens a blank document.