Как я могу избежать нескольких утверждений в этом unit test?

Ответ 1

Я бы сказал, что в духе вещи это прекрасно. Причина, по которой несколько утверждений "зла", если я правильно помню, заключается в том, что это означает, что вы тестируете несколько вещей в одном тесте. В этом случае вы действительно делаете это, проверяя каждое поле, предположительно, чтобы убедиться, что это работает для нескольких разных типов. Так как все испытания на равенство объектов все равно, я думаю, что вы в явном виде.

Если вы действительно хотели воинствовать об этом, напишите один тест на каждое свойство (j/k!)

Ответ 2

Несколько утверждений за unit test отлично подходят для моей книги, если несколько утверждений утверждают одно и то же условие теста. В вашем случае они проверяют, что преобразование было успешным, поэтому проверка прохождения является условной для всех утверждений, являющихся истинными. В результате это прекрасно!

Я бы классифицировал "одно утверждение за тест" в качестве ориентира, а не жесткое правило. Когда вы игнорируете это, подумайте, почему вы игнорируете его.

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

public class ClassWithProperities
{
    public string Foo { get; set; }
    public int Bar { get; set; }
}

public static class Converter
{
    public static ClassWithProperities Convert(string foo, int bar)
    {
        return new ClassWithProperities {Foo=foo, Bar=bar};
    }
}
[TestClass]
public class PropertyTestsWhenFooIsTestAndBarIsOne
{
    private static ClassWithProperities classWithProperties;

    [ClassInitialize]
    public static void ClassInit(TestContext testContext)
    {
        //Arrange
        string foo = "test";
        int bar = 1;
        //Act
        classWithProperties = Converter.Convert(foo, bar);
        //Assert
    }

    [TestMethod]
    public void AssertFooIsTest()
    {
        Assert.AreEqual("test", classWithProperties.Foo);
    }

    [TestMethod]
    public void AssertBarIsOne()
    {
        Assert.AreEqual(1, classWithProperties.Bar);
    }
}

[TestClass]
public class PropertyTestsWhenFooIsXyzAndBarIsTwoThousand
{
    private static ClassWithProperities classWithProperties;

    [ClassInitialize]
    public static void ClassInit(TestContext testContext)
    {
        //Arrange
        string foo = "Xyz";
        int bar = 2000;
        //Act
        classWithProperties = Converter.Convert(foo, bar);
        //Assert
    }

    [TestMethod]
    public void AssertFooIsXyz()
    {
        Assert.AreEqual("Xyz", classWithProperties.Foo);
    }

    [TestMethod]
    public void AssertBarIsTwoThousand()
    {
        Assert.AreEqual(2000, classWithProperties.Bar);
    }
}

Ответ 3

Я согласен со всеми остальными комментариями, что это хорошо, если вы логически проверяете одно.

Однако существует разница между множеством утверждений в одном unit test, чем с отдельным unit test для каждого свойства. Я называю это "Блокировка утверждений" (вероятно, лучшее название там). Если у вас много утверждений в одном тесте, вы узнаете только об отказе в первом свойстве, которое не подтвердило утверждение. Если вы скажете, что 10 свойств и 5 из них возвратили неверные результаты, вам придется пройти через исправление первого, повторно запустить тест и заметить, что другой не удалось, затем исправить это и т.д.

В зависимости от того, как вы смотрите на это, это может быть довольно неприятно. На оборотной стороне, имеющей 5 простых модульных тестов, которые внезапно могут оказаться неудачными, также можно было отказаться от установки, но это может дать вам более четкое представление о том, что привело к тому, что они все сразу потерпели неудачу и, возможно, быстрее перенаправили вас к известному исправлению (возможно).

Я бы сказал, что если вам нужно протестировать несколько свойств, сохраните номер вниз (возможно, до 5), чтобы избежать проблемы с блокировкой, выходящей из-под контроля. Если есть тонна свойств для тестирования, то, возможно, это признак того, что ваша модель представляет слишком много, или, возможно, вы можете посмотреть, как группировать свойства в несколько тестов.

Ответ 4

Эти 3 утверждения действительны. Если вы использовали фреймворк, более похожий на mspec, он выглядел бы так:

public class When_converting_a_TestPoco_to_Recordset
{
    protected static List<TestPoco> inputs;
    protected static Recordset actual;

    Establish context = () => inputs = new List<TestPoco> { new TestPoco { /* set values */ } };

    Because of = () => actual = input.ToRecordset ();

    It should_have_copied_the_bool_value = () => actual.BoolValue.ShouldBeTrue ();
    It should_have_copied_the_int_value = () => actual.Int32Value.ShouldBe (1);
    It should_have_copied_the_String_value = () => actual.StringValue.ShouldBe ("foo");
}

Обычно я использую mspec в качестве эталона, чтобы узнать, имеют ли смысл мои тесты. Ваши тесты хорошо читаются с помощью mspec, и это дает мне некоторые полуавтоматические теплые пушистики, которые я тестирую правильно.

В этом отношении вы сделали лучшую работу с несколькими утверждениями. Я ненавижу просмотр тестов, которые выглядят так:

Assert.That (actual.BoolValue == true && actual.Int32Value == 1 && actual.StringValue == "foo");

Потому что, когда это не удается, сообщение об ошибке "Ожидание True, получившее False" совершенно бесполезно. Множество утверждений и максимально возможное использование инфраструктуры тестирования модулей помогут вам многое.

Ответ 5

Это должно быть что-то, чтобы проверить http://rauchy.net/oapt/ Инструмент, который генерирует новый тестовый пример для каждого утверждения.