Test result has ^M characters and is not on multiple lines.

[DasOhmoff]

Hey 👋, thank you for your help.

I like this plugin a lot, and that is why I am starting to use it everywhere. I started using it for testing also, and I noticed something. Suppose I have the following code:

        [Fact]
        public void Test()
        {
            Assert.True(false);
        }

If I now execute OmniSharpRunTest, I get the following result in the quick fix window:

Notice the ^M character, and also that the message is only on one single line, instead of multi lines. It would be great to have these ^M characters removed and the message separated onto separate lines.

There is already something similar there in omnisharp-vim. In which the stacktrace is printed on multiple lines. For example if you have the following code:

        [Fact]
        public void Test()
        {
            Assert.True(false);
        }

        private void PrivateMethod()
        {
            Assert.True(false);
        }

If I now execute OmniSharpRunTest within the Test method, I get the following result in the quick fix window:

Here the stacktrace is separated onto multiple lines.

By the way: Also it would be nice to be able to change the color of the message parts, for example the stacktrace to red.

I think this should not take to long to implement. What do you think?
Thank you :)

[nickspoons]

The problem is that the quickfix window is not just a special buffer: each line of the quickfix buffer is a specific quickfix entry, corresponding to a code location. So splitting a line into multiple lines isn't really how the quickfix window works.

So the first line you see is the actual test failure message. When the test framework returns this as multiple lines it has to be joined. This is also the only way we can display the failure when running multiple tests, using :OmniSharpRunTestsInFile.

When running a single test, the stack trace will be displayed as well. This is something I added recently and it still makes sense because each line of the stack trace is also a specific location.

Colouring the stack trace differently is also not trivial, as this isn't just an ordinary buffer or printed output. You could do it with matchadd() in a QuickFixCmdPost autocmd which somehow recognises that this quickfix is a test result (possibly recognising the 'quickfixtextfunc' property?) but it's quite fiddly. And I don't really see the value - the first line is the test failure description, the rest of the lines are the stack trace, there's not much there for colours to help distinguish. Perhaps setting a specific QuickFixLine highlight group would help you? As the first quickfix entry will initially be selected (the test failure message), this means that the first line will initially be highlighted as QuickFixLine while the rest is highlighted as Normal. I personally have this in my config (called as part of an autocmd ColorScheme):

highlight QuickFixLine ctermbg=236 guibg=#32302f cterm=italic gui=italic

[DasOhmoff]

Yeah, I see what you are saying, and it does came sense.

Another idea: Then what if I somehow was able to retrieve more information from the quick fix entry. For example if I have some results in my quickfix window, and then I use the command OmniSharpShowTestDetails or so to display a popup window containing more information about the currently selected quickfix window test entry (the full message with line breaks, the full stacktrace with line breaks, etc)

[nickspoons]

Yeah that would be the other way to go. In that case we wouldn't necessarily use the quickfix list at all, but instead create a custom window which we could handle as we liked. It would have its own filetype and get its own syntax highlighting (as we do with the omnisharplog and omisharpdoc filetypes), and then we could make custom mappings for navigation etc.

Other benefits could be:

• displaying stack traces (in closed folds?) for all tests run, not just when running a single test
• display System.Console output (currently only visible by running messages after running tests)
• provide a single location for running tests from multiple files, or from the entire project

However. This is a lot of work! It does start to sound like a cool feature though. A full "test runner" hub.

[DasOhmoff]

Yeah! That is even a lot better! That sound great great 😙👌. I know this is a lot of effort, but please make it happen :D

[nickspoons]

@DasOhmoff have a look at #789

[DasOhmoff]

That is perfect. Thanks!