Thank you very much for your work, Emily! By coincedence this extension solves one of problems I have with my personal project. I've thought to make something similar myself, and it's really nice that I can focus on other tasks instead. Thank you very much indeed.
Would be nice if extension could also adress diagnostics specific for used unit-testing tool. It is especially useful for errored tests because, as I see it, error of test is an inherently tool-specific state. But it would be useful for other outcomes as well - tool can report warnings even if test passed.
Let me explain my use case: I work with ceedling test adapter (C language) and tests could be errored (currently they reported as failed, but I'm planning to fix it) if code syntax is wrong or if compilation or linking failed. Also I can get warnings if code is considered wrong but compiles anyway. All of these problems reported from used toolchain (GCC in my case) to stderr, which is then could be passed in TestEvent message field - as I understood from comment above this field it's intended for this exact purpose - reporting of problems.
VSC already has a mechanism for parsing such tool-specific problems - Tasks with problemMatchers. It's regex-based - output of tool is just scanned with regular expressions to find problems information - file, line, etc. Unfortunately it seems like it's not usable in this case (at least I've not figured a way to use it) - problemMatchers-related code is not accessible directly from extensions and Tasks are not not suitable because tool could be executed multiple times when running test suites - problems reported by Task would be cleared before each execution.
So, as I see it, the most proper way of implementing this would be to copy implementation of problemMatchers from VSC source code (it's in problemMatcher.ts file) to extension and make it configurable from extension settings. Algorithm is something like "if there is problem-matching patterns defined in extension settings, search for them in message field of every TestEvent and report diagnostics accordingly".
Now, why I think this should be in this extension rather than in tool-specific test adapters. First, adapters are not necessarily tool-specific - I use Ceedling tool, but I can swap underlying compiler and messages would be different. Second - if test adapters were handling their diagnostics themselves, this extension would not be needed, but it is - so it's only logical to implement this feature here.
Sorry for wall of text and thanks for your time. I intend to contribute btw.