aarnott / xunit.stafact

Run your xunit-based tests on an STA thread with the WPF Dispatcher, a WinForms SynchronizationContext, or even a cross-platform generic UI thread emulation with a SynchronizationContext that keeps code running on a "main thread" for that test.

Xunit.StaFact

Run your xunit-based tests on an STA thread with the WPF Dispatcher, a WinForms SynchronizationContext, or even a cross-platform generic UI thread emulation with a SynchronizationContext that keeps code running on a "main thread" for that test.

Simply use [WpfFact], [WinFormsFact], [StaFact] or the cross-platform [UIFact] on your test method to run your test under conditions that most closely match the main thread in your application.

Theory variants of these attributes allow for parameterized testing. Check out the xunit.combinatorial nuget package for pairwise or combinatorial testing with theories.

Features

The following test attributes are supported:

Xunit test attributes	Supported OS's	SynchronizationContext	STA thread?
[UIFact, UITheory]	All	Yes¹	yes²
[WpfFact, WpfTheory]	Windows only³	DispatcherSynchronizationContext	yes
[WinFormsFact, WinFormsTheory]	Windows only³	WindowsFormsSynchronizationContext	yes
[StaFact, StaTheory]	Windows only³	No	yes
[CocoaFact, CocoaTheory]	Mac OSX only³	Yes¹	no

¹ This is a private SynchronizationContext that works cross-platform and effectively keeps code running on the test's starting thread the way a GUI application's main thread would do.

² STA thread only applies on Windows. On other operating systems, an MTA thread is used.

³ Windows-only attributes result in the test to result in "Skipped" on other operating systems.

We also offer a [UISettingsAttribute] that can be applied to individual test methods or test classes to control the behavior of the various UI test attributes. This attribute offers a means to add automated retries to a test's execution for unstable tests.

Samples

[UIFact] // or [WinFormsFact] or [WpfFact]
public async Task WpfFact_OnSTAThread()
{
    Assert.Equal(ApartmentState.STA, Thread.CurrentThread.GetApartmentState());
    int originalThread = Environment.CurrentManagedThreadId;
    await Task.Yield();
    Assert.Equal(originalThread, Environment.CurrentManagedThreadId); // still there
}

See more samples.

xunit.stafact's Issues

Can't run tests

Using VS2019 16.3.7. Running any test with the [WpfFact]/[StaFact]/[UIFact] attribute causes:

[11/5/2019 7:27:06.971 AM Informational] [xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.4.1 (32-bit Desktop .NET 4.0.30319.42000)
[11/5/2019 7:27:07.233 AM Warning] [xUnit.net 00:00:00.27] <AssemblyName>: Catastrophic error during deserialization: System.ArgumentException: Could not load type 'Xunit.Sdk.UITestCase, Xunit.StaFact' from serialization value 'Xunit.Sdk.UITestCase, Xunit.StaFact:VGVzdE1ld...(elided)'
Parameter name: serializedValue
   at Xunit.Sdk.SerializationHelper.Deserialize[T](String serializedValue) in C:\Dev\xunit\xunit\src\common\SerializationHelper.cs:line 35
   at Xunit.Sdk.XunitTestFrameworkExecutor.Deserialize(String value) in C:\Dev\xunit\xunit\src\xunit.execution\Sdk\Frameworks\XunitTestFrameworkExecutor.cs:line 84
   at Xunit.DefaultTestCaseBulkDeserializer.<BulkDeserialize>b__2_0(String serialization) in C:\Dev\xunit\xunit\src\xunit.runner.utility\Descriptor\DefaultTestCaseBulkDeserializer.cs:line 22
   at System.Linq.Enumerable.<>c__DisplayClass7_0`3.<CombineSelectors>b__0(TSource x)
   at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   at Xunit.DefaultTestCaseBulkDeserializer.BulkDeserialize(List`1 serializations) in C:\Dev\xunit\xunit\src\xunit.runner.utility\Descriptor\DefaultTestCaseBulkDeserializer.cs:line 22
   at Xunit.Xunit2.BulkDeserialize(List`1 serializations) in C:\Dev\xunit\xunit\src\xunit.runner.utility\Frameworks\v2\Xunit2.cs:line 74
   at Xunit.Runner.VisualStudio.VsTestRunner.RunTestsInAssembly(IRunContext runContext, IFrameworkHandle frameworkHandle, LoggerHelper logger, TestPlatformContext testPlatformContext, RunSettings runSettings, IMessageSinkWithTypes reporterMessageHandler, AssemblyRunInfo runInfo) in C:\Dev\xunit\xunit\src\xunit.runner.visualstudio\VsTestRunner.cs:line 562

Add UITheory and StaTheory

Just wondering if there's any plan to add theory attributes for the other types of facts. Right now, the only theory is WpfTheory.

Thanks :)

Custom Thread

Hi,

We have a custom thread, which have made which is similar to the WinForms UI thread. It involves wrapping all tests with something like:

using var dispatcher = new CustomDispatcher();
await dispatcher.InvokeAsync(() =>
{
     [Original Test Code]
}

What would be the best way to extend your package here ? Or is there a simpler way in Xunit to get this functionality ?

Thanks

Generate test arguments on test thread

Xunit.StaFact should create test argument data on the same thread that it eventually runs the test on. This allows for thread affinitized data objects to be created and then run properly within the test.

The best news is that xunit.stafact does control the thread that this in-proc re-generation of data runs on:

 	Xunit.StaFact.Tests.dll!StaTheoryTests.NonSerializableObject.NonSerializableObject() Line 27	C#
 	Xunit.StaFact.Tests.dll!StaTheoryTests.NonSerializableData.get() Line 34	C#
 	[Native to Managed Transition]	
 	[Managed to Native Transition]	
 	xunit.core.dll!Xunit.MemberDataAttributeBase.GetData(System.Reflection.MethodInfo testMethod) Line 66	C#
 	xunit.core.dll!Xunit.Sdk.DataDiscoverer.GetData(Xunit.Abstractions.IAttributeInfo dataAttribute, Xunit.Abstractions.IMethodInfo testMethod) Line 25	C#
 	xunit.execution.desktop.dll!Xunit.Sdk.XunitTheoryTestCaseRunner.AfterTestCaseStartingAsync() Line 92	C#
 	xunit.execution.desktop.dll!Xunit.Sdk.TestCaseRunner<Xunit.Sdk.IXunitTestCase>.RunAsync() Line 81	C#
>	Xunit.StaFact.dll!Xunit.Sdk.UITheoryTestCase.RunAsync(Xunit.Abstractions.IMessageSink diagnosticMessageSink, Xunit.Sdk.IMessageBus messageBus, object[] constructorArguments, Xunit.Sdk.ExceptionAggregator aggregator, System.Threading.CancellationTokenSource cancellationTokenSource) Line 29	C#
 	xunit.execution.desktop.dll!Xunit.Sdk.XunitTestMethodRunner.RunTestCaseAsync(Xunit.Sdk.IXunitTestCase testCase) Line 45	C#

Originally posted by @AArnott in dotnet/winforms#3209 (comment)

CollectionAttribute seems to be not respected

WinForms has some tests that cannot be executed in parallel, the corresponding class has an attribute [Collection("Sequential")] which is supposed to put all test methods of that class in a collection and execute them in sequence (the name is probably irrelevant, as far as I understand its just grouping by collection name, but I didn't research this in detail).

/cc @hughbe @RussKie @AArnott

StaTheory does not work with MemberDataAttribute

I tried combination of StaTheory and MemberDataAttribute. It says that parameters are not provided for the method. However WpfTheory works fine

STA for Fixture Collections

I tried to put some intialization code in a fixture collection and it is crashing because it is not STA.
Could it be possible to have fixture collection constructor and dispose on STA?

Thanks

StaFact tests not being discovered in .net core 3.0 using xUnit 2.4.0 and "dotnet.exe xunit.console.dll"

I already contacted you about this but I figured I'd create an issue so it can be tracked.

I'm building windows forms using .net core 3.0 from github and I have some tests using xUnit. A few of our tests need STA, so I tried using [StaFact] but it seems the test discovery is not working for me and I'm not sure why.

[StaFact] tests not found when used with netcoreapp2.2

If I create a simple test project dotnet new xunit targeting netcoreapp2.2, and dotnet add sample.csproj package Xunit.StaFact --version 0.3.18, change example [Fact] to [StaFact], and no tests are found when running dotnet test.

Suggestion: Skip support (SkippableFact)

Trying to do UI testing with StaFact but then I would also like to be able to skip tests. However, adding both a SkippableFact and a StaFact attribute causes xunit to fail on not supporting multiple Fact-derived attributes. If trying to call Skip.If(true) anyway, then the Xunit.SkipException is thrown and unhandled, causing the test case to fail.

Support for .Net 4.7?

I would like to use this package with .Net 4.7. Is there any chance to that it can be updated to support the latest verison of .Net Standard?

Running all tests within a class on the same thread?

Would it be possible to add an option to run all tests within a class on the same thread? Right now all tests run on an STA thread but not on the same STA thread. I ran into problems where different UI components end up on different threads which causes failures.

See this merge request for an example of a workaround.

The behavior can be observed by making the following change to the constructor of StaFactTests.

    public StaFactTests(ITestOutputHelper testOutputHelper)
    {
        Assert.Equal(ApartmentState.STA, Thread.CurrentThread.GetApartmentState());
        testOutputHelper.WriteLine("Currently on thread {0}", Thread.CurrentThread.ManagedThreadId);
    }

Running the test will print the following lines (with varying numbers):

Currently on thread 22
Currently on thread 23
Currently on thread 24

StaFact facts breaks the concurrency limitations of Xunit

Xunit has an internally implemented limitation of tests to be executed concurrently. This is implemented based on fixed number of threads executing the tests.

All Fact implementations of StaFact packages creating its own thread, e.g. UIFact, will break the Xunit limitation because the Xunit thread is released after UIFact test execution has been started. I think this causes unexpected high CPU load while test execution resulting in accidental failed test execution, e.g. fluentassertions/fluentassertions#1391 and https://ci.appveyor.com/project/dennisdoomen/fluentassertions/builds/37160306

I've created and attached a sample project showing the problem. For demonstration I've configured the limitation to 2 concurrent tests. All standard Fact tests completing successfully. Most UIFact tests will fail because the maximum number of tests is exceeded.

StaFactTests.zip

InvalidComObjectException on test cleanup when window is shown

InvalidComObjectException: COM object that has been separated from its underlying RCW cannot be used.

is thrown when a window is shown in a WpfFact. Example:

[WpfFact]
public void ShouldShowWindow()
{
    var window = new Window();
    window.Show();

    Assert.True(window.IsVisible);
}

The cause and solution is mentioned here: http://stackoverflow.com/questions/17194361/why-closing-window-created-in-a-unit-test-raises-an-invalidcomobjectexception

I made some changes in a fork to get us over the line: #5
Hopefully it can be incorporated, let me know if I need to change any conventions in the pull request.

Regards,

netstandard support

Hi

any plans to it?

Unmanaged memory and handles leak

Hi,
I have detected a huge memory and handles leak during my porting our legacy tests from old version of nunit to xunit. Test runner has been crashed after ~1000 test suits with out of memory exception, ~2 gb unmanaged memory was taken, managed heap was ~250 mb. After investigating this issue i have found a problem, you are creating a new thread for each test suite. I have fixed it in my fork using thread pool. Xarlot@fb2c15d
However, it added an additional external reference, so i prefer to write an issue than create a pull request.

internal/*broken*/ for WpfTheory

I really love STAFact. However I'd like to level up to using STATheory or WPFTheory. However in the source code it is marked as broken. Is this something fundamental and difficult to fix or an oversight?

https://github.com/AArnott/Xunit.StaFact/blob/master/src/Xunit.StaFact/WpfTheoryAttribute.cs

StaTheory is not supported in Visual Studio Runner

Example

// Licensed to the .NET Foundation under one or more agreements.
// The .NET Foundation licenses this file to you under the MIT license.
// See the LICENSE file in the project root for more information.

using System.Collections.Generic;
using WinForms.Common.Tests;
using Xunit;

namespace System.Windows.Forms.Tests
{
    public class WebBrowserTests
    {
        public static IEnumerable<object[]> Parent_Set_TestData()
        {
           // yield return new object[] { null };
            yield return new object[] { new Control() };
        }

        [StaTheory]
        [MemberData(nameof(Parent_Set_TestData))]
        public void WebBrowser_Parent_Set_GetReturnsExpected(Control parent)
        {
            var browser = new WebBrowser
            {
                Parent = parent
            };
            Assert.Same(parent, browser.Parent);
            Assert.Null(browser.ActiveXInstance);
            Assert.False(browser.IsHandleCreated);
        }
    }
}

[9/23/2019 7:22:30.780 PM Informational] ---------- Discovery started ----------
[9/23/2019 7:22:33.339 PM Informational] [xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.4.1 (32-bit Desktop .NET 4.0.30319.42000)
[9/23/2019 7:22:34.552 PM Informational] [xUnit.net 00:00:01.26]   Discovering: WinformsTest
[9/23/2019 7:22:35.854 PM Informational] [xUnit.net 00:00:02.40]   Discovered:  WinformsTest
[9/23/2019 7:22:35.855 PM Informational] [xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.4.1 (32-bit Universal Windows)
[9/23/2019 7:22:36.060 PM Informational] ========== Discovery finished: 85 tests found (0:00:05.2286991) ==========
[9/23/2019 7:22:36.116 PM Informational] ---------- Run started ----------
[9/23/2019 7:22:38.520 PM Informational] [xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.4.1 (32-bit Desktop .NET 4.0.30319.42000)
[9/23/2019 7:22:40.388 PM Error] [xUnit.net 00:00:01.88] WinformsTest: Test case System.Windows.Forms.Tests.WebBrowserTests.WebBrowser_Parent_SetWithHandle_GetReturnsExpected failed to deserialize: Test case deserialization failure: System.InvalidOperationException: Could not de-serialize type 'Xunit.Sdk.UITheoryTestCase' because it lacks a parameterless constructor.
   at Xunit.Serialization.XunitSerializationInfo.DeserializeSerializable(Type type, String serializedValue) in C:\Dev\xunit\xunit\src\common\XunitSerializationInfo.cs:line 213
   at Xunit.Serialization.XunitSerializationInfo.Deserialize(Type type, String serializedValue) in C:\Dev\xunit\xunit\src\common\XunitSerializationInfo.cs:line 110
   at Xunit.Sdk.SerializationHelper.Deserialize[T](String serializedValue) in C:\Dev\xunit\xunit\src\common\SerializationHelper.cs:line 40
   at Xunit.Sdk.XunitTestFrameworkExecutor.Deserialize(String value) in C:\Dev\xunit\xunit\src\xunit.execution\Sdk\Frameworks\XunitTestFrameworkExecutor.cs:line 84
   at Xunit.Sdk.TestCaseBulkDeserializer.Deserialize(ITestFrameworkDiscoverer discoverer, ITestFrameworkExecutor executor, String serialization) in C:\Dev\xunit\xunit\src\xunit.execution\Sdk\TestCaseBulkDeserializer.cs:line 33
[9/23/2019 7:22:40.390 PM Error] [xUnit.net 00:00:01.88] WinformsTest: Test case System.Windows.Forms.Tests.WebBrowserTests.WebBrowser_Parent_Set_GetReturnsExpected failed to deserialize: Test case deserialization failure: System.InvalidOperationException: Could not de-serialize type 'Xunit.Sdk.UITheoryTestCase' because it lacks a parameterless constructor.
   at Xunit.Serialization.XunitSerializationInfo.DeserializeSerializable(Type type, String serializedValue) in C:\Dev\xunit\xunit\src\common\XunitSerializationInfo.cs:line 213
   at Xunit.Serialization.XunitSerializationInfo.Deserialize(Type type, String serializedValue) in C:\Dev\xunit\xunit\src\common\XunitSerializationInfo.cs:line 110
   at Xunit.Sdk.SerializationHelper.Deserialize[T](String serializedValue) in C:\Dev\xunit\xunit\src\common\SerializationHelper.cs:line 40
   at Xunit.Sdk.XunitTestFrameworkExecutor.Deserialize(String value) in C:\Dev\xunit\xunit\src\xunit.execution\Sdk\Frameworks\XunitTestFrameworkExecutor.cs:line 84
   at Xunit.Sdk.TestCaseBulkDeserializer.Deserialize(ITestFrameworkDiscoverer discoverer, ITestFrameworkExecutor executor, String serialization) in C:\Dev\xunit\xunit\src\xunit.execution\Sdk\TestCaseBulkDeserializer.cs:line 33
[9/23/2019 7:22:40.416 PM Informational] [xUnit.net 00:00:01.89]   Starting:    WinformsTest
[9/23/2019 7:22:47.282 PM Informational] [xUnit.net 00:00:08.77]   Finished:    WinformsTest
[9/23/2019 7:22:47.807 PM Informational] ========== Run finished: 628 tests run (0:00:11.4979809) ==========

.net 4.5.2 compatibility

Please keep Nuget package compatibility with .net 4.5.2
The latest Nuget 1.0.37 has no .net 4.5.2 support.

[StaFact] tests do not execute when targeting net462

When using the previous version 0.3.18 the [StaFact] attribute worked on my tests but now when upgrading to 1.0.37 it doesn't seem to work. The test starts but then it stops immediately and gets the status inconclusive.
Only change I have done is to upgrade from 0.3.18 to 1.0.37.

Feature Request: STA Test Constructors

I have case where I have to initialize my Testclass with some UI (WPF) code, requiring STA Execution. Therefore it would be great if I was able to mark the constructor / test initalizer as [StaInitalizer] (or whatever you want to call it.

Hanging UITheoryTestCase

Running tests in WinForms from command line hangs. These hangs do not happen when running tests from Visual Studio or via dotnet test. It looks like UITheoryTestCase doesn't get disposed.

I've isolated the hang to a standalone repo: https://github.com/weltkante/XUnitStaFactWinFormsHang

Opening a console and changing working directory to the build output, the (reduced) command line used to run the tests is: dotnet exec --depsfile XUnitStaFactTest.deps.json --runtimeconfig XUnitStaFactTest.runtimeconfig.json "C:\Users\Tobias\.nuget\packages\xunit.runner.console/2.4.1/tools/netcoreapp2.0/xunit.console.dll" XUnitStaFactTest.dll -noautoreporters

CPU usage in polling message loop

PumpTill has a polling message loop that even though its yielding the thread still causes high CPU load. This can be done better, at least in WinForms. An example how to do a CPU friendly modal loop is here

Tests 'pass' when they throw OperationCanceledException

awaiting an async operation with timeout causes the test to report as passed when the timeout expires. Perhaps the test framework is swallowing OperationCanceledException or something.

Support for OleInitialize

OLE has an explicit OleInitialize native call which is required in addition to STA for OLE based functions and COM classes to work properly. This came up in the discussion of dotnet/winforms#1999 and recent list of unstable tests which all target OLE interfaces.

A bunch of classes like ComponentManager, Clipboard, AxHost etc. do call Application.OleRequired to setup/verify STA. But when testing the internals of WinForms you often don't go through those public APIs and test the OLE APIs more directly, so you are missing the OleInitialize call and I think this may at least partly responsible for unstable tests:

dotnet/winforms#2002
dotnet/winforms#2003
dotnet/winforms#2004
dotnet/winforms#2005

There has been no analysis done yet to verify whether calling Application.OleRequired will fix above tests, but considering that WinFormsFactAttribute is already using a Windows­Forms­Synchronization­Context it may be reasonable to also call Application.OleRequired on that thread just in case the tests will need OLE.

WPF support on .NET Core 3.0 breaks .NET Core 3.0 consumers on Linux/Mac

The mere presence of WPF support on .NET Core 3.0 for this package injects artifacts into the package nuspec file that breaks the build for anyone depending on this package and building on mac/linux and targeting .NET Core 3.0. Even though they don't care about WPF, the dependency breaks the build.

See dotnet/sdk#3592

We'll need to break up WPF support on .NET Core 3.0 into its own package, evidently. :(

Clarify attribute names, or rename package ID

You are going to release version 1.0. That's great!
But I would like to take the (last) chance to ask whether the naming of the attributes is "as good as possible".

I'm so far a bit confused about the many different versions.
Currently I'm using the UIFact because I want to have a thread with SynchronizationContext applied, even my use case in not a UI thread.

Could you please check again the names, e.g. by creating overview documentation when to use which version?

Finally a recommendation just from my point of view:

• UIFact is not really for UI. There are more specific version with WpfFact and WinFormsFact.
• This attribute could be named like one of the following
  • SCFact (synchronizaton context fact, very close to STAFact)
  • ContextFact (readable, but not fully qualified)

I'll update this list as soon I have new ideas. Maybe you have additional ideas!?

[MainThreadFact] to execute tests on main thread on macos

Hi! I have a native library that requires to be interacted with only from main thread on macos. Can this project provide a way to do it?

Expected result

public class MainThreadTests
{
    [MainThreadFact]
    public void TestIt()
    {
        Assert.Equal(1, Thread.CurrentThread.ManagedThreadId);
    }
}

WpfTheory with MemberData parameters deserialization failure

Hello,

After updating our WPF project XUnit version for test cases, a lot of tests started failing due to STA Threads. Installing StaFact library and using WpfFact and WpfTheory helped a lot in solving those issues.

However, after converting some of our Theory to WpfTheory, some of them that contains MemberData objects provided started to fail to run giving the following exception:
------ Run test started ------
[xUnit.net 00:00:05.4308436] IPC.POS.Tests: Test case ScreenBaseTest.ScreenBaseTest_SetBrandMenuEnabled failed to deserialize: Test case deserialization failure: System.InvalidOperationException: Could not de-serialize type 'Xunit.Sdk.WpfTheoryTestCase' because it lacks a parameterless constructor.
at Xunit.Serialization.XunitSerializationInfo.DeserializeSerializable(Type type, String serializedValue)
at Xunit.Serialization.XunitSerializationInfo.Deserialize(Type type, String serializedValue)
at Xunit.Sdk.SerializationHelper.Deserialize[T](String serializedValue)
at Xunit.Sdk.TestFrameworkExecutor`1.Deserialize(String value)
at Xunit.Sdk.XunitTestFrameworkExecutor.Deserialize(String value)
at Xunit.Sdk.TestCaseBulkDeserializer.Deserialize(ITestFrameworkDiscoverer discoverer, ITestFrameworkExecutor executor, String serialization)
[xUnit.net 00:00:14.8414221] Starting: Tests
[xUnit.net 00:00:15.0974942] Finished: Tests
System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain. This can happen if the test(s) started a thread but did not stop it. Make sure that all the threads started by the test(s) are stopped before completion.
========== Run test finished: 0 run (0:00:24.1873834) ==========

If i revert to using Theory, I can see that the parameters are deserialized correctly and unit test run, but using WpfTheory gives me the mentioned exception for same objects provided and unit test is not run.

Any feedback would be appreciated.

Thanks.

WinUI Unit testing with UIFact doesn't appear to work.

I created a WinUI project for testing some BitmapImage-related code using MSTest along the lines recommended here: https://devblogs.microsoft.com/ifdef-windows/winui-desktop-unit-tests/ and immediately ran into problems trying to use UITestMethod with async calls (e.g. BitmapImage.SetSourceAsync) and went down a rabbit hole using TaskCompletionSource and dispatching the bulk of the test to the UI thread, and then tried to address issues with waiting for XAML to render (because, in WinUI, you can't get at the bits in a BitmapImage, but you can render it into the Xaml tree and then use a RenderTargetBitmap to get the rendered pixels). What a joke.

I'd really prefer to use Xunit for my tests (as I've done for non-UI code -- though this is only UI code by necessity as described above).

So...
This led me to modify this: https://github.com/AArnott/Xunit.StaFact/blob/main/test/Xunit.StaFact.Tests/WindowsDesktop/WpfFactTests.cs to use the WinUI synchronization context to try to get it to work on a WinUI project, like so:

using DesktopSyncContext = Microsoft.UI.Dispatching.DispatcherQueueSynchronizationContext;

I also had to remove the "ShouldShowWindow" test case because that's not how WinUI does what that test is trying to assert. With only those two changes, it fails to run. I get no errors, but see these warnings:

Starting test discovery for requested test run
========== Starting test discovery ==========
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.4.5+1caef2f33e (64-bit .NET 7.0.5)
No test is available in WinUI3TestApp1.exe. Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again.
========== Test discovery finished: 0 Tests found in 4 sec ==========
========== Starting test run ==========
========== Test run finished: 0 Tests (0 Passed, 0 Failed, 0 Skipped) run in < 1 ms ==========

The no test available message is odd, given that all the tests show up in the test explorer.

If I set a breakpoint and debug the first test, it's never hit. To reiterate, this is not my code, but code from the Xunit.StaFact repository with the two changes noted above. I'm at a loss as to how to get this to work.

Is this supported? Has anyone been able to do WinUI/WindowsAppSdk 1.3/.Net 6+ UI testing with Xunit, with or without Xuint.StaFact? If so, what are the steps? If it's not supported, what would it take to add that support. I'm probably willing to participate in doing the work if it comes to that.

Thanks in advance.