Introduction

In NUnit, Assert.Equals is a trap for people expecting it to behave like a real test assertion. It is not the same as Assert.AreEqual or Assert.That, and NUnit actively throws an exception to stop you from misusing it. The fix is simple: use one of NUnit’s actual assertion APIs and treat Assert.Equals as off-limits in tests.

Why Assert.Equals Fails

Assert.Equals comes from System.Object. It is not NUnit’s equality assertion API. Because this mistake was so common, NUnit explicitly throws when developers try to use it as an assertion.

Bad example:

1using NUnit.Framework;
2
3[TestFixture]
4public class CalculatorTests
5{
6    [Test]
7    public void WrongAssertionExample()
8    {
9        int expected = 4;
10        int actual = 2 + 2;
11
12        Assert.Equals(expected, actual);
13    }
14}

That code does not express a real NUnit test assertion and will trigger the message saying Assert.Equals should not be used for assertions.

Use Assert.AreEqual for Direct Equality Checks

If you want a straightforward equality assertion, use Assert.AreEqual.

1using NUnit.Framework;
2
3[TestFixture]
4public class CalculatorTests
5{
6    [Test]
7    public void AreEqualExample()
8    {
9        int expected = 4;
10        int actual = 2 + 2;
11
12        Assert.AreEqual(expected, actual);
13    }
14}

This is the classic NUnit style and works well for simple value comparisons.

Prefer Assert.That for Readable, Extensible Assertions

Modern NUnit code often prefers the constraint model with Assert.That.

1using NUnit.Framework;
2
3[TestFixture]
4public class CalculatorTests
5{
6    [Test]
7    public void ConstraintExample()
8    {
9        int result = 2 + 2;
10
11        Assert.That(result, Is.EqualTo(4));
12    }
13}

This style scales better when assertions become more expressive, such as ranges, collection properties, or string matching.

For example:

1using NUnit.Framework;
2
3[TestFixture]
4public class StringTests
5{
6    [Test]
7    public void StringAssertionExample()
8    {
9        string value = "NUnit";
10
11        Assert.That(value, Does.StartWith("NU").IgnoreCase);
12    }
13}

That is one reason many teams standardize on Assert.That.

Know the Difference Between Equality Methods

There are several related methods with different meanings:

• 'Assert.AreEqual(expected, actual) checks value equality'
• 'Assert.AreSame(expected, actual) checks object identity'
• 'Assert.AreNotEqual(expected, actual) checks inequality'
• 'Assert.That(actual, Is.EqualTo(expected)) checks equality through the constraint model'

Use the method that matches what you are actually testing.

For example, reference identity is not the same as equal content:

1using NUnit.Framework;
2
3[TestFixture]
4public class ReferenceTests
5{
6    [Test]
7    public void SameVsEqual()
8    {
9        var a = new string("abc".ToCharArray());
10        var b = new string("abc".ToCharArray());
11
12        Assert.AreEqual(a, b);
13        Assert.AreNotSame(a, b);
14    }
15}

Why NUnit Chooses to Throw

The exception is deliberate. If NUnit silently allowed Assert.Equals, many tests would appear meaningful while actually using the wrong method semantics. Failing fast is better than letting misleading tests pass through code review.

This is one of those cases where the framework is protecting you from a subtle but common API confusion.

Refactor Old Tests Safely

If you inherit a codebase containing Assert.Equals, replace those calls systematically.

A simple rule:

• if the intention is equality, convert to Assert.AreEqual or Assert.That(..., Is.EqualTo(...))
• if the intention is identity, convert to Assert.AreSame

Example refactor:

1// old and wrong
2Assert.Equals(expected, actual);
3
4// new and correct
5Assert.That(actual, Is.EqualTo(expected));

After refactoring, run the test suite because some mistaken uses of Assert.Equals may have hidden incorrect expectations.

Team Style Guidance

If your team is deciding between Assert.AreEqual and Assert.That, the important part is consistency. Both are valid, but mixed styles inside the same test class can make code harder to scan.

Many teams choose:

• 'Assert.That for new code'
• 'Assert.AreEqual only in older tests or simple direct comparisons'

Whatever you choose, ban Assert.Equals in review.

Common Pitfalls

One common mistake is assuming any method named Equals inside Assert must be a real NUnit assertion. It is not.

Another issue is using AreSame when the test really wants value equality. That produces brittle tests for strings, DTOs, and value objects.

A third mistake is doing broad search-and-replace without understanding whether each failing test intended equality or identity.

Summary

• 'Assert.Equals is not a valid NUnit assertion method.'
• Use Assert.AreEqual or Assert.That(..., Is.EqualTo(...)) for value equality.
• Use Assert.AreSame only when object identity is the goal.
• NUnit throws intentionally to prevent misleading tests.
• If you see Assert.Equals in a test suite, replace it as part of cleanup.