Changing DefaultFloatingPointTolerance breaks tests running in parallel

[CharliePoole]

GlobalSettings.DefaultFloatingPointTolerance is a static. When it is changed for a single test, other tests may be affected. Even if the test resets it to the original value in TearDown, any tests that run in parallel with the test making the change are affected.

We should deprecate the GlobalSettings class (this is its sole member) and provide some other way to change the default tolerance. As it stands, the default tolerance should only be set at the command-line or in a global SetUpFixture.

[CharliePoole]

This keeps breaking the build. I'm going to put in a temporary fix, at least.

[CharliePoole]

PR #1950 does a temporary fix for our own tests but this remains open to deal with removing (first deprecating) GlobalSettings and creating an alternative way to change the default for a test. This will most likely be a thread-based setting in the TestExecutionContext.

I'm removing my assignment, in case somebody else wants to take this on after the release.

[ChrisMaddock]

What did you see the user API to this looking like, @CharliePoole? Just a command line option/FrameworkPackageSetting? Should there be a way to set it per test?

I'm tempted to just go command line option, until people ask for more.

[CharliePoole]

It's already a command-line option and package setting. But that's the default. What happens when a fixture or method wants to work with a different default? One approach is to just make the global settings obsolete and have users specify any non-default tolerance on each assertion. Another would be to define an attribute that implements IApplyToContext and sets the context default to a different value.

IIRC, once you get the value into the execution context it will be used automagically. That needs to be checked. The good thing is that if you set it on a class, it will apply just for the tests in that class and if you set it on a method it will only apply for that method.

I'm not sure how important this is. In fact, we only use it in tests that test the feature itself. 😄 But it would be worth cleaning up if only to get those tests of ours to run in parallel.

[ChrisMaddock]

It's already a command-line option and package setting.

Is it? I don't see either, am I missing something?

One approach is to just make the global settings obsolete and have users specify any non-default tolerance on each assertion.

I'd be tempted to go with this, up until we find out someone needs something more general. 😄 I was seeing this just as an issue to tidy up something a bit buggy.