This may be a more appropriate place to follow up with issues, since the UserVoice suggestion has been completed.
Unfortunately this feature is not usable yet. The message is not formatted and AggregateException is not unwrapped as I had asked. There isn't much room for the column. I want to see `Assert.AreEqual failed. Expected:<1>. Actual:<2>.` That will barely fit in the window already, but there's no way I'm going to see it when the column actually contains: `System.AggregateException: One or more errors occurred. ---> Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException: Assert.AreEqual failed. Expected:<1>. Actual:<2>.`
Currently, I only have enough room for it to show `System.AggregateException: One or more erro...`.
I am never going to want to see AggregateException. If someday it matters, the fact that the exception was wrapped in an AggregateException is something I can see from the results pane when I click on it.
For the column, please strip any wrapping AggregateExceptions and put the Message property first, followed by the short name of the type (.GetType().Name). Something like this: "{message} [{type}]".
Unfortunately, this is now becoming much more complicated, as NCrunch now needs to pick apart exception data to try and construct this report. There are also edge cases to consider (i.e. what about aggregate exceptions that have their own physical type descending from aggregateexception?).
This feature was implemented because simply placing an exception message into a column was very easy to do ... though what you are requesting is much more involved. Unfortunately I'll need to see more demand on the uservoice request before I can justify the effort needed to make such a change. Sorry.
Unfortunately, this is now becoming much more complicated, as NCrunch now needs to pick apart exception data to try and construct this report. There are also edge cases to consider (i.e. what about aggregate exceptions that have their own physical type descending from aggregateexception?).
This feature was implemented because simply placing an exception message into a column was very easy to do ... though what you are requesting is much more involved. Unfortunately I'll need to see more demand on the uservoice request before I can justify the effort needed to make such a change. Sorry.
My plea is that I just need to be able to see expected vs actual in the column.
It wouldn't take much. This is all I would want dropped in:
string FormatShortMessage(Exception ex)
{
if (ex.GetType() == typeof(AggregateException) && ex.InnerException != null) ex = ex.InnerException;
return $"{ex.Message} [{ex.GetType().Name}]";
}
jnm236 wrote:
What's the risk? Worst case, the column is unusable. But the column wasn't available in the first place.
The data you're asking for isn't sitting in the UI where it can be easily obtained.
It would need to be extracted and parsed at test runtime because it relies on runtime exception objects. Which means it needs to be obtained for every test exception for every user, regardless of whether they are using the column or not.
The data needs to be piped up from the runtime environment, through the grid nodes and compressed over a network, through the engine, through the IPC barrier between the engine and the UI. There would need to be handling for edge cases such as stack traces written in different languages (i.e. German etc), or people using derived types of AggregateException ... these are the issues that on first glance I already know about, there are likely to be additional unknown unknowns.
It's not a 'big deal', but we're no longer looking at simply just adding a small piece of data to a column. To justify making these changes and carrying their weight through the lifetime of the product, I'd need to be sure there is a good number of people that would make use of the feature.
That's a perfectly reasonable constraint. On the flip side, that information clarifies the problem at hand. Exception objects aren't strictly the domain of what we are interested anyway. The domain is text. All I need is to be able to trim the beginning so the message portion is visible.
With that in mind, please consider this:
string FormatShortMessage(string fullMessageText)
{
const string aggregateExceptionPrefix = "System.AggregateException: One or more errors occurred. ---> ";
if (fullMessageText.StartsWith(aggregateExceptionPrefix, StringComparison.Ordinal))
fullMessageText = fullMessageText.Substring(aggregateExceptionPrefix.Length);
const string assertFailedException = "Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException: ";
if (fullMessageText.StartsWith(assertFailedException, StringComparison.Ordinal))
fullMessageText = fullMessageText.Substring(assertFailedException.Length);
return fullMessageText;
}
This is actually incredibly safe because you are matching exact text, text which you already know you don't want to see, rather than doing semantic parsing to achieve that as a byproduct.
I know your reaction might be "what about languages other than English," but there is no harm waiting until that is requested. The ability to see multiple exception messages would be huge for me.