Testy jednostkowe: odroczone twierdzenia z Linq

Czy można dodawać odroczone twierdzenia w ten sposób?

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

Dlaczego? Mogę więc powtórzyć tylko raz, nawet w przypadku stwierdzeń oczekujących zmaterializowanej kolekcji, na przykład:

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

Może to być nie tylko Select, ale metoda ze zdefiniowanym iteratorem i mająca wiele kontroli i logiki (np. Zliczanie i filtrowanie).

Nasieniem wątpliwości jest złożoność odczytu i debugowania takiego kodu w przypadku niepowodzenia testu.

Czy można dodawać odroczone twierdzenia takie jak ten [..]

Nie , nie jest. Dlaczego? Ponieważ jeśli z jakiegokolwiek powodu usuniesz drugie stwierdzenie, test nadal zmieni kolor na zielony i uważasz, że nadal działa, ale nie działa, ponieważ kolekcja nie zostanie wyliczona. Jeśli masz dwa lub więcej niezależnych stwierdzeń, będą wykonywać swoją pracę nawet po wyłączeniu jednego z nich.

Rozważ tę kombinację:

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

Teraz nawet jeśli wyłączysz lub usuniesz jeden z twierdzeń, drugi nadal wykona swoją pracę. Również jeśli zapomnisz zmaterializować kolekcję, jej uruchomienie może potrwać dłużej, ale nadal będzie działać. Niezależne testy są bardziej niezawodne i niezawodne.

Jest też drugie nie . Nie jestem pewien, jak radzą sobie z tym inne frameworki, ale jeśli używasz platformy MS Test, nie wiedziałbyś, który test się nie powiódł. Jeśli klikniesz dwukrotnie test zakończony niepowodzeniem, wyświetli się komunikat „zakończony CollectionAssertniepowodzeniem”, ale w rzeczywistości zagnieżdżenie się nie powiodło Asserti bardzo trudno będzie go debugować. Oto przykład:

    [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()); 

    }

Oznacza to, że pierwszy test jest faktycznie bezużyteczny, ponieważ nie pomaga znaleźć błędu. Nie wiesz, czy nie powiódł się, ponieważ numer był nieprawidłowy lub ponieważ obie kolekcje były różne.

Dlaczego? Mogę więc powtórzyć tylko raz, nawet z oświadczeniami oczekującymi zmaterializowanej kolekcji

Zastanawiam się, dlaczego ci na tym zależy? To są testy jednostkowe. Nie musisz optymalizować każdego z nich i zwykle testy nie wymagają milionów elementów, więc wydajność nie powinna być problemem.

Musisz utrzymywać takie testy, więc dlaczego miałbyś je bardziej skomplikować niż to konieczne? Napisz proste stwierdzenia, które działają.