Welcome Guest! To enable all features please Login or Register.



NCrunch could deliver a little more detail with exceptions on analysis
#1 Posted : Friday, August 9, 2019 12:27:20 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 5/17/2011(UTC)
Posts: 173

Thanks: 8 times
Was thanked: 37 time(s) in 34 post(s)

i discovered a problem on a test suite in a project, NCrunch helped to find the problem, but i maybe could give more information.

Here is the problem.

The complete description, Stacktrace and more you find in the repro repository. https://github.com/DerAlbertCom/MisbehavingUnittestRunners

But because of this part in the Stacktrace

at Xunit.Sdk.TestFrameworkDiscoverer.FindTestsForTypeAndWrapExceptions(ITestClass testClass, Boolean includeSourceInformation, IMessageBus messageBus, ITestFrameworkDiscoveryOptions discoveryOptions) in C:\Dev\xunit\xunit\src\xunit.execution\Sdk\Frameworks\TestFrameworkDiscoverer.cs:line 156
at nCrunch.Module.XUnit2.Integration.XUnit2DiscoveryEnvironment.FindFrameworkTestsInAssembly(ReflectedAssembly assembly, FilePath assemblyFilePath, IList`1 referencedAssemblyFilePaths, ComponentUniqueName testComponentUniqueName, PlatformType platformType, DynamicProxy[] dynamicProxies)

I assume that FindTestsForTypeAndWrapExceptions gets called for every type in an assembly, so NCrunch could catch the exception and report the type name on which the error occured. In an ideal case xUnit would report TypeName and MethodName, i will file an issue for that. But a long that don't happend it would be nice if NCrunch could tell the Type AND also go on with the analysis on the rest of the types in the assembly.
#2 Posted : Saturday, August 10, 2019 12:12:25 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,090

Thanks: 792 times
Was thanked: 1036 time(s) in 986 post(s)
Thanks for sharing this. It does look to be an internal exception kicked up by Xunit.

The stack trace above doesn't seem to be complete. I'm not sure if this is due to the availability of debug information, but there is at least one step missing on the call stack here. When we discover tests, we make a call to the ITestFrameworkDiscoverer.Find method, which itself sits above the routine that enumerates types in the assembly and discovers tests. The overall enumeration of the assembly and all its metadata is handled entirely by Xunit, and we just respond to messages it sends back to us during/after the enumeration. This means that when it blows up like this, we really have no information other than the exception message. Sorry, but I don't see a way for us to improve on this.
#3 Posted : Saturday, August 10, 2019 1:39:08 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 5/17/2011(UTC)
Posts: 173

Thanks: 8 times
Was thanked: 37 time(s) in 34 post(s)
You find the complete Stacktrace and more Information in the readme.md of the repro repository. Yes, it is an Exception von Xunit, but i asume that in nCrunch.Module.XUnit2.Integration.XUnit2DiscoveryEnvironment.FindFrameworkTestsInAssem you call xUnit for every type. You may catch the exception at that type end put the xunit exception in an innerexception. It would be a workaround for xUnit (and maybe other frameworks) and it would be only for misbehaving test discovery. It is not a high priority problem, but would helped more in that case.
Users browsing this topic
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.032 seconds.