Question

Je suis récemment tombé sur un comportement apparemment étrange que Google a complètement omis d'expliquer.


using Microsoft.VisualStudio.TestTools.UnitTesting;

class TestClass
{
    public override bool Equals(object obj)
    {
        return true;
    }
}

[TestMethod]
public void TestMethod1()
{
    TestClass t = new TestClass ();
    Assert.AreEqual (t, null); // fails
    Assert.IsTrue (t.Equals (null)); // passes
}

Je m'attendrais à ce que ce test réussisse. Cependant, dans Visual Studio 2008 / .NET 3.5, cela échoue. Est-ce que c'est destiné à être comme ça ou est-ce un bug?

Était-ce utile?

La solution

Votre TestClass enfreint le contrat Object.Equals . Assert.AreEqual s'appuie assez raisonnablement sur ce contrat.

L'état de la documentation (dans la liste des exigences):

  • x.Equals (une référence null (rien dans Visual Basic)) renvoie false.

Autres conseils

Lors du test des valeurs NULL, n'utilisez pas Assert.AreEqual .

Vous devez utiliser Assert.IsNull () pour cela.

Le premier test échoue. Testez si " t " est null, ce qui n'est pas le cas, car vous avez initialisé le t avec un nouvel objet TestClass.

Le deuxième test est réussi, car t.Equals renvoie toujours la valeur true.

Si un test échoue, l'ensemble de TestMethod1 est marqué comme ayant échoué.

Non, c’est correct - vous avez initialisé t à un nouvel objet TestClass, qui n’est pas nul, donc l’assertion échoue.

Si je vous comprends bien, il est en fait prévu que AreEqual (anyButNull, null) renvoie toujours false?

(éditer) La raison pour laquelle je me demandais est que le test de null, comme requis par le contrat d’égalité, n’est pas appelé lors de l’analyse de la classe. Donc, parce qu'AreEqual s'appuie sur le contrat, il ne vérifie pas si ma classe respecte également le contrat. Donc, je suppose que je dois utiliser la solution de contournement de Assert.IsFalse (blah.Equals (null)) .

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top