Pergunta

i recentemente deparei com um comportamento aparentemente estranho que o Google falhou completamente para explicar.


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
}

Espero que este teste para ter sucesso. No entanto, em Visual Studio 2008 / .NET 3.5 ele falhar. É destinado a ser assim ou é um bug?

Foi útil?

Solução

Seu TestClass viola o contrato de Object.Equals . Assert.AreEqual está contando com esse contrato, bastante razoável.

O estado docs (na lista de requisitos):

  • x.Equals (uma referência nula (Nada no Visual Basic)) retorna false.

Outras dicas

Ao testar para valores nulos, não use Assert.AreEqual.

Você tem que usar Assert.IsNull() para isso.

O primeiro teste falhar. Teste se "t" é nulo, o que não é, porque você inicializado o t com um novo objeto TestClass.

O segundo teste, passa, porque t.Equals sempre retorna true.

Se um teste falhar, toda a TestMethod1 é marcado como falhou.

Não, não é correta -. Você inicializado t para um novo TestClass objeto, que não é nulo, então a declaração falha

Se eu te direito, é realmente pretende que AreEqual(anythingButNull, null) sempre retornar falso?

(edit) A razão que eu perguntei é porque o teste para nulo, conforme exigido pelo contrato de iguais, não é chamado quando UnitTesting a classe. Então porque AreEqual conta com o contrato, ele não consegue verificar se a minha classe também está em conformidade com o contrato. Então eu acho que tem que usar a solução de Assert.IsFalse(blah.Equals(null)).

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top