feat: add xUnit testing harness

[mxschmitt]

First stab for adding xUnit testing harness for Playwright since they changed their parallelism algorithm which unblocked us. So far I found the following questions along the way:

• Microsoft.Playwright.xUnit vs Microsoft.Playwright.XUnit
• Is it normal that Console.WriteLine doesn't work in the test method? I had to follow this guide instead to make it work. Looks like we can use Console / Trace / Debugger capture support xunit/xunit#1730 (comment) once its released.
• Do we stick with AppDomain.CurrentDomain.FirstChanceException to determine if a test failed and restart the worker services (mostly Browser) appropriately? Inspired by @SimonCropp from here. We need some hack since there is no TestContext in xUnit.
  • Looks like if we target only xUnit.v3 then we could use the TestContext as per feat: add xUnit testing harness #3044 (comment).
• Is targeting net8.0 fine? AppDomain is only available in net5.0+. xUnit itself targets net472;net6.0. Maybe we should target both as well and provide AppDomain support only for the net6.0 output.

Curious about your inputs @kblok @campersau @nohwnd thank you in advance!

Relates #2977

[campersau]

Is it normal that Console.WriteLine doesn't work in the test method?

Yes.

Do we stick with AppDomain.CurrentDomain.FirstChanceException to determine if a test failed and restart the worker services appropriately?

If you wait a little xunit.v3 will be released and it contains new features like a TestContext and CaptureConsoleAttribute which might help.
See

• v3 Roadmap xunit/xunit#2133
• Changes to TheoryData break tests with arrays of objects xunit/xunit#3031 (comment)

[kblok]

• Microsoft.Playwright.xUnit vs Microsoft.Playwright.XUnit

Maybe we could follow their name xunit, Microsoft.Playwright.xunit. Not that pretty. Microsoft.Playwright.XUnit would be my second choice.

• Is it normal that Console.WriteLine doesn't work in the test method? I had to follow this guide instead to make it work. Looks like we can use Console / Trace / Debugger capture support xunit/xunit#1730 (comment) once its released.

Yes. That was a headache. We were using XunitLoggerProvider in the old days.

[nohwnd]

I don't have any comments to the code, it all looks pretty good / standard to me.

I would name the namespace, Microsoft.Playwright.Xunit, because it is the least special, and also how they capitalize their namespace / class. https://github.com/xunit/xunit/blob/main/src/xunit.v3.runner.utility/Frameworks/v2/Xunit2.cs#L15

And the nuget Microsoft.Playwright.XUnit. Because I see the capitalization with existing packages all over the place.

@bradwilson do you have different preferences on the capitalization of the xunit name?

[bradwilson]

In theory, the only capitalization "rules" are:

• Product name = xUnit.net
• Class name or namespace name = Xunit

In practice, people do whatever they want. 😁

The product name being "xUnit.net" is really because back in the day, "xUnit" meant "replace 'x' with something that represents your programming environment". SUnit = Smalltalk, JUnit = Java, NUnit = .NET. Since NUnit was already taken, we opted for "xUnit.net" as the next best name. (And by "we" I mean @jnewkirk who also was part of creating NUnit. 😉)

File names or package names, we don't care about. We use all lowercase for ours, but we've never asked anybody to follow that pattern. Frankly it's like that mostly because I'm an Extra Oldster™️ who likes lowercase file names because of case sensitive file systems.

[bradwilson]

I will say, XUnit looks wrong to my eyes, but that's a bit of personal preference. I think for package names Xunit would be better than XUnit; or if you feel strongly about capitalizing the U, then use xUnit. We never capitalize the X and U together.

[nohwnd]

I don’t feel strongly about the name, but I do prefer I prefer Xunit over xUnit in the package name.

[yury-s]

Do we need all this service code right away? If so, can it at least be shared with other runners?