InternalTraceLevel.Default turns on logging

[estrizhok]

As mentioned in this issue, NUnit3TestAdapter 4.3.0 causes empty log files to be created on every discovery/execution in either solution directory, if tests in question target .NETCore, or in bin directory, if it is old .NETFramework.

Now, version 4.3.1 of the adapter when running tests using Visual Studio runner does not have this problem as promised. However, the root cause does not seem to have been fixed:

NUnit.Engine.TestEngine turns on logging during initialization if InternalTraceLevel is not Off. And the default value for this property is Default, causing empty log files creation when running tests using R#/Rider.

We can, of course, set trace level explicitly to Off, as - it seems - has been done in the VS adapter. But I have a feeling that turning on empty log file creation by default on every TestEngine initialization is probably a bug.

nunit.engine 3.15.2.0

[butterworld]

Confirmed this is still an issue as for nunit.engine 3.16.3. It's problematic when an executable is run from C:\Program Files, which of course doesn't (and shouldn't) have write permissions.

[CharliePoole]

@estrizhok The int value of Default is 0, which results in an uninitialized InternalTraceLevel always being set as Default. The intention in doing it this way is that each runner could change Default to the appropriate setting, as the adapter does. Apparently Rider doesn't do that. To allow for runners which don't change the setting, the engine could do it but only after the test runner has failed to do so in the initialization sequence.

FWIW, there's a cleaner fix for this in the 4.0 codebase, which I was not able to implement in the 3.x branch.

@butterworld The default setting for where result and log files are saved is based on the current directory at the time of execution not the location of the executable, so it's actually in control of the runner. Of course, there are also options to have them saved elsewhere.

[OsirisTerje]

@butterworld @estrizhok This should be fixed with adapter 4.4.2. It uses an embedded engine based on the 3.15.2 code, a 3.15.3-ish version. I will try to get that released asap.
The 3.16.3 version have multiple issues with loading, and I am not at all sure how that could be fixed. I will try to have a look at the 4.0 code, but that will be awhile. So the best bet if you would like to update is the upcoming 3.15.3.

[CharliePoole]

This has been an issue in several releases and been "fixed" several times in the past. It doesn't seem to be in the current main and version3X branches any longer.