Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix for issue #1178 based on fix in PR #1214 for version 3.17++ #1394

Merged
merged 1 commit into from
Apr 3, 2024

Conversation

OsirisTerje
Copy link
Member

No description provided.

Copy link
Member

@stevenaw stevenaw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM thanks @OsirisTerje
Changes appear to match the original PR. Out of curiosity, why leave the old code commented instead of removing?

// See PR 1114 https://github.com/nunit/nunit-console/pull/1214/files
engine.InternalTraceLevel = Options.InternalTraceLevel != null
? (InternalTraceLevel)Enum.Parse(typeof(InternalTraceLevel), Options.InternalTraceLevel)
: InternalTraceLevel.Off;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want the default to be InternalTraceLevel.Off why doesn't the TestEngineActivator.CreateInstance ensure that?
Now it explicitly requires switching off.
Would this not affect other places where an engine is created (e.g. the adapter)

In the engine the level is set as: public InternalTraceLevel InternalTraceLevel { get; set; } = InternalTraceLevel.Default;
Where Default < Off.

However in its Initalize method it only tests on Off.
Instead of Default being its own state, should we not have Default = Off or drop Default completely?

            if(InternalTraceLevel != InternalTraceLevel.Off && !InternalTrace.Initialized)
            {
                var logName = string.Format("InternalTrace.{0}.log", Process.GetCurrentProcess().Id);
                InternalTrace.Initialize(Path.Combine(WorkDirectory, logName), InternalTraceLevel);
            }

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally yes, but I am very shaky on everything here, so I don't dare doing too much now. We have three sort of main branches, and they are very diverged. So this is just part of it, and I try to do as little as possible to make them even more diverged.

I am also very uncertain about what to do with the v4 (main) here, since it is not working, and is not finished, and I don't have enough information to know what is missing or not.

@OsirisTerje
Copy link
Member Author

OsirisTerje commented Apr 3, 2024

@stevenaw That piece of code has been ported all over the different branches in exactly that way. As said above (answer to Manfred), the branches are a mess, and I just want to keep the code changes "as is" for now.
Once (hopefully) we get this cleaned up, stuff like this should go.

@OsirisTerje OsirisTerje merged commit 2e6b8bc into version3X Apr 3, 2024
2 checks passed
@OsirisTerje OsirisTerje deleted the Issue1178 branch April 3, 2024 07:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants