Open tannergooding opened 6 years ago
@jonsequitur any clue? It should not be possible... everything is in memory
When this runs in prodcon is it using the corefx/coreclr that was built before it?
Another theory is the code uses == for assertion. But it is object equal. String interning could cause this problem.
No, string overloads operator ==(a, b) to be the same as String.Equals(a, b)
true, without any extra stuff and the type of e is string.
public static bool operator ==(String a, String b)
{
return String.Equals(a, b);
}
ContainSingle
accepts an expression, not a delegate. Depending on how FluentAssertions uses that expression, the result could be a call to object.Equals, which, if the string is not interned, can result in a false
, e.g.:
object obj = "String";
string str = typeof(string).Name;
Console.WriteLine($"{obj} == {str}?"); // --> String == String?
Console.WriteLine(obj == str); // --> False
The question is why this would vary based on the build.
We're guessing that changing the comparison from ==
to .Equals
might fix the problem.
Interesting take. Treating that expression as object equals would be a bug in FluentAssertions. Seems like we should dig in, verify that, and report it to them if we can demonstrate that's indeed what's happening.
It looks to me like FluentAssertions uses Expression<T>.Compile()
so if there's a bug in the interpretation it would be there.
@tannergooding Repeating my question: Does prodcon execution of these tests use a just-built coreclr/corefx?
@mmitche might be a better person to ask.
Does prodcon execution of these tests use a just-built coreclr/corefx?
@tannergooding No
@mmitche No, it doesn't get a just-built copy, or no you're not the better person to ask? ;)
@nguerrera It doesn't use a just-build coreclr/corefx
The
When_no_option_accepts_arguments_but_one_is_supplied_then_an_error_is_returned
parsing validation test is failing in prodcon with:The test is not failing locally in any of the configurations I tested.