Testes unitários: asserções adiadas com Linq

Posso adicionar asserções adiadas como esta

var actualKittens = actualKittens.Select(kitten => {
    Assert.IsСute(kitten);
    return kitten
});

Por quê? Então, eu posso iterar apenas uma vez, mesmo com instruções que esperam uma coleta materializada, por exemplo:

CollectionAssert.AreEquivalent(expectedKittens, actualKittens.ToList());

E também pode ser não apenas Select, mas um método com o iterador definido e com muitas verificações e lógica (por exemplo, algumas contagens e filtros).

A semente da dúvida é a complexidade de ler e depurar esse código em caso de falha no teste.

Tudo bem adicionar declarações adiadas como esta [..]

Não é não. Por quê? Porque, se por algum motivo você remover a segunda declaração, o teste ainda ficará verde e você achará que ainda funciona, mas não funciona, pois a coleção não será enumerada. Se você tiver duas ou mais afirmações independentes, elas continuarão realizando seu trabalho, mesmo que você desative uma delas.

Considere esta combinação:

Assert.IsTrue(actualKittens.All(x => x.IsCute());
CollectionAssert.AreEquivalent(expectedKittens, actualKittens.ToList());

Agora, mesmo que você desative ou remova uma das afirmações, a outra ainda fará seu trabalho. Além disso, se você esquecer de materializar a coleção, poderá levar mais tempo para executar, mas ainda funcionará. Testes independentes são mais robustos e confiáveis.

Há também um segundo não . Não tenho certeza de como outras estruturas lidam com isso, mas se você estiver usando a plataforma MS Test, não saberá qual teste falhou. Se você clicar duas vezes no teste que falhou, ele mostrará o CollectionAssertque falhou, mas, na realidade, foi o aninhado Assertque deu errado e será extremamente difícil depurar. Aqui está um exemplo:

    [TestMethod]
    public void TestMethod()
    {
        var numbers = new[] { 1, 2, 3 }.Select(x =>
        {
            Assert.Fail("Wrong number.");
            return x;
        });

        // This will fail and you won't be sure why.
        CollectionAssert.AreEqual(new[] { 1, 2, 3 }, numbers.ToList()); 

    }

Isso significa que o primeiro teste é realmente inútil porque não ajuda a encontrar um bug. Você não sabe se houve falha porque um número era inválido ou porque as duas coleções eram diferentes.

Por quê? Para que eu possa iterar apenas uma vez, mesmo com instruções que esperam uma coleta materializada

Eu me pergunto por que você se importa com isso? Estes são testes de unidade. Você não precisa otimizar cada um deles e, geralmente, os testes não requerem milhões de itens, portanto o desempenho não deve ser uma preocupação.

Você precisará manter esses testes. Por que você deve torná-los mais complexos do que o necessário? Escreva afirmações simples que funcionem.