Providing custom source file information to [Fact]/[Theory] tests

[egil]

Hi @bradwilson, et. al.,

I am back with more bUnit related questions:

I want to enable writing regular xUnit tests inside Blazor .razor files, e.g. MyTest.razor:

@using Xunit
@code
{
    [Fact]
    public void Test() { ... }

    [Theory]
    [InlineData("foo")]
    public void DataDrivenTest(string input) { ... }
}

This works, but a key feature is the navigate to test from the Test Explorer in Visual Studio by double clicking the test name, doesn't work, since the MyTest.razor is compiled to a MyTest.razor.g.cs C# file placed in the obj\Debug\net5.0\Razor folder.

The custom test discoverer you (Brad) helped me write previously for the Razor based tests in bUnit works well and is required since those tests doesn't have anything related to xUnit on them, like the usual [Fact] or [Theory] attributes.

However, since the new tests will basically be regular xUnit test methods, just in a .razor file, I wonder if there is a smarter/simpler approach I can take?

To give an idea of what is available in the generated C# source file, the one for the above example looks roughly like this:

#pragma checksum "C:\source\bUnit\examples\MyTest.razor" "{ff1816ec-aa5e-4d10-87f7-6f4963833460}" "962b7f7bc4a3b12b6352aa215e782e2ff4708a2b"
// <auto-generated/>
#pragma warning disable 1591
namespace Bunit.RazorTesting
{
    // .. removed imports for brevity.
#line default
#line hidden
#nullable disable
    public partial class NewTestComponentBaseTest : TestContext
    {
        #pragma warning disable 1998
        protected override void BuildRenderTree(Microsoft.AspNetCore.Components.Rendering.RenderTreeBuilder __builder)
        {
        }
        #pragma warning restore 1998
#nullable restore
#line 3 "C:\source\bUnit\examples\MyTest.razor"
 
	[Fact]
	public void Test() { /* ... */ }

	[Theory]
	[InlineData("foo")]
	public void DataDrivenTest(string input) { /* ... */ }

#line default
#line hidden
#nullable disable
    }
}
#pragma warning restore 1591

[bradwilson]

Soooo... I assume this doesn't work? I'm surprised. I would've expected this to just do the right thing, because the #line directive should be embedding new source & line number information into the PDB, yes? If not, then that's definitely a question for someone on the .NET team to figure out how to get this to map appropriate into the PDB (which is what I assume the DiaSession stuff from Visual Studio relies upon).

[egil]

It didn't work in my simple test project. But I just assumed that it was up to xUnit to figure this sort of things out, so haven't experienced with the various embed stuff in pdb build setting.

Are you expecting the #line pragma to just make this work?

[bradwilson]

Well, nothing that xUnit.net is doing cares about source information. The only valid source information provider in the system is the one that uses DiaSession when you're running inside Visual Studio. I have never looked inside it to understand what it's doing, and whether that's going to work inside Visual Studio or not is honestly a question for the VSTest team to field, not us.

[egil]

I'll try to find somebody in the VSTest to ask. Thanks for the input.