The `Assert.AreEqual(object, object)` is very error prone and poor design

Description

Due the fact that the Assert static class has an AreEqual(object, object) the compiler is always able to find a valid match during compilation if a type changes on one side of the assertion. This means all failures must be found very late in the game (read: after compilation and tests have been run).

This is generally not desirable. Either the AreEqual(object, object) method should go away, or a more strict version of AreEqual should introduced. An ideal API might be

void Equality<T>(T expected, T actual) where T: IEquatable; 
void Equality<T>(T expected, T actual, IEqualityComparer<T> comparer);
void SameObject(object expected, object actual); // performs ReferenceEquals(expected, actual)

With this triple alone, a test suite would cover 99% of equality tests without having to worry about the duck-typing mess we have today.

Steps to reproduce

Setup a test with Assert.AreEqual(0, obj.value) with obj.value starting as an int, then change the type to TimeSpan (or whatever). It’ll compile happily but fail when tests are run.

In a tiny project this is not a major issue, but in a large project where compilation take 45+ minutes and test runs can last an hour or more, this is a major time waster.

Expected behavior

.NET solutions not using duck-typing.

Actual behavior

MSTest uses duck-typing because … ?

Environment

Windows 10, Visual Studio 2017, NetFx 4.6.2, stock MSTest nuget packages.

[AbhitejJohn]

Thanks folks. Would you mind giving the issue a 👍 and we’ll prioritize this. Sounds like we’d want to mark the API as obsolete for a few release so users are aware and remove it in the next major. /cc: @nohwnd

[Evangelink]

We will add some analyzers that will prevent some issues on this. In parallel, we will make the object, object overload obsolete.