What does TraceListenerQueue do

[gasparnagy]

@obligaron asked: What is the purpose of TraceListenerQueue? It's not normally used. Even after removing the code, all the tests still passed.

[gasparnagy]

This is a good question and I answer it here, so that we have a record.

In the earliest versions of SpecFlow, we designed an interface called ITraceListener, that was printing out the messages the tests produced to the console. The idea was that the listener can be replaced by for example a file-based logging. (Note that this was long before the dotnet test or the generic TRX output file time. At that time test logging had no generic concept or solution. At that time, parallel execution was not even considered.)

As the trace logging was a "global" concern, the ITraceListener interface was registered in the "global" (test-run) container, so the implementation was a singleton.

Later, I think when one of the test runner (xunit?) provided a built-in test output logger (and parallel execution appeared in the horizon), we realized that our concept no longer works because that logger was test specific, so we could not use it in our global listener.

The idea was that we provide a "local" trace listener that the tests can use (registered in the "test-thread" container) and one in the "global" that everyone else can. If the local is not overridden it should forward all messages to the "global" (in a thread-safe, asynchronous way): the "local" is by default implemented with the AsyncTraceListener class, that forwards the messages to the ITraceListenerQueue implementation (registered at global, thread safe), that forwards the messages to the "global" trace listener using a background thread.

However, due to rush, backwards compatibility and maybe some laziness, we did not separate the "local" and the "global" trace listener properly at interface level, but both use the ITraceListener interface. This causes some ongoing confusion.

At the current time, all supported test runner (xunit, mstest, nunit) has its own output messaging infrastructure, so basically they all capture the messages themselves and never forward the messages to the "global" listener. This is why it seems that currently the TraceListenerQueue is not used.

I'm open to clean up this. Please suggest.