Setting thread names to make debugging easier

[jnm2]

Right now it's not easily distinguishable which threads are NUnit's, and specifically which are part of its MTA queues or STA queues.

[OsirisTerje]

Makes good sense.
We should prefix all threads we create with "NUnit." and probably also add which component is creating the thread, framework, engine, console or adapter. The name could be a bit long though, so perhaps use a short name for the component.

I also see the thread named "EventPumpThread". A bit surprised it is not named "StandardEventPumpThread", as that should be the name, according to the code.

nunit/src/NUnitFramework/framework/Internal/Execution/EventPump.cs

Line 137 in af7b941

Name = $"{Name}EventPumpThread",

and

nunit/src/NUnitFramework/framework/Internal/Execution/EventPump.cs

Line 93 in af7b941

protected EventPump(TListener eventListener, EventQueue<TEvent> events, string name = "Standard")

, and only one usage which doesn't change it.

[stevenaw]

I like this idea. Improved observability and debugging experience is always a good thing

[manfred-brands]

I agree for threads we create.
However isn't is that in fully async code the thread running a test can change between awaits.

[OsirisTerje]

Yes, it can only be for our own threads.
Async/await may change threads, so thread names and tests are not strongly connected. But I would assume it would in any case look better than the screen shot @jnm2 has above.

[jnm2]

Yep. In my case the tests weren't async. When the test is async, then the execution may end up on a thread pool thread. (If the test is marked STA then NUnit keeps it on the same thread even if an await suspends the async method. Same if a Windows Forms or WPF message pump was present before the test method started executing.)

[OsirisTerje]

Just for a simple test, I got this: