Модульные тесты: отложенные утверждения с Linq

Это нормально, чтобы добавить отложенные утверждения, как это

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

Почему? Так что я могу выполнить итерацию только один раз, даже если операторы ожидают материализованную коллекцию, например:

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

А также это может быть не просто Select, но метод с определенным итератором, имеющий много проверок и логику (например, некоторые подсчеты и фильтрации).

Семя сомнений заключается в сложности чтения и отладки такого кода в случае неудачного тестирования.

Можно ли добавить отложенные утверждения, подобные этому [..]

Нет , это не так. Почему? Потому что, если вы по какой-либо причине удалите второе утверждение, тест все равно станет зеленым, и вы подумаете, что он все еще работает, но это не так, поскольку коллекция не будет перечислена. Если у вас есть два или более независимых утверждения, они будут продолжать выполнять свою работу, даже если вы отключите одно из них.

Рассмотрим эту комбинацию:

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

Теперь, даже если вы отключите или удалите одно из утверждений, другое все равно выполнит свою работу. Также, если вы забудете материализовать коллекцию, ее запуск может занять больше времени, но она все равно будет работать. Независимые тесты являются более надежными и надежными.

Существует также второй нет . Я не уверен, как другие фреймворки справляются с этим, но если вы используете платформу MS Test, вы не узнаете, какой тест не удался. Если вы дважды щелкнете по неудачному тесту, он покажет вам, CollectionAssertкак неудачный, но на самом деле это была вложенная Assertошибка, и отладка будет чрезвычайно сложной. Вот пример:

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

    }

Это означает, что первый тест на самом деле бесполезен, потому что он не помогает найти ошибку. Вы не знаете, произошел ли сбой, потому что число было недействительным или потому что обе коллекции были разными.

Почему? Так что я могу повторить только один раз, даже если операторы ожидают материализованную коллекцию

Интересно, почему вы заботитесь об этом? Это юнит-тесты. Вам не нужно оптимизировать каждый их бит, и обычно тесты не требуют миллионов элементов, поэтому производительность не должна быть проблемой.

Вам нужно будет поддерживать такие тесты, так почему вы должны сделать их более сложными, чем необходимо? Напишите простые утверждения, которые работают.