Лучшие практики для нескольких утверждают на том же результате в C#

Question

Лучшие практики для нескольких утверждают на том же результате в C#

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

[TestFixture]
public class GridControllerTests
{
    protected readonly string RequestedViewId = "A1";

    protected GridViewModel Result { get; set;}

    [TestFixtureSetUp]
    public void Get_UsingStaticSettings_Assign()
    {
        var dataRepository = new XmlRepository("test.xml");

        var settingsRepository = new StaticViewSettingsRepository();

        var controller = new GridController(dataRepository, settingsRepository);

        this.Result = controller.Get(RequestedViewId);

    }

    [Test]
    public void Get_UsingStaticSettings_NotNull()
    {
        Assert.That(this.Result,Is.Not.Null);
    }

    [Test]
    public void Get_UsingStaticSettings_HasData()
    {
        Assert.That(this.Result.Data,Is.Not.Null);
        Assert.That(this.Result.Data.Count,Is.GreaterThan(0));
    }

    [Test]
    public void Get_UsingStaticSettings_IdMatches()
    {
        Assert.That(this.Result.State.ViewId,Is.EqualTo(RequestedViewId));
    }

    [Test]
    public void Get_UsingStaticSettings_FirstTimePageIsOne()
    {
        Assert.That(this.Result.State.CurrentPage, Is.EqualTo(1));
    }
}

10

c# tdd nunit assert assertions

задан asdseee 14 January 2010 в 09:40

4 ответа

Другие вопросы по тегам:

c# tdd nunit assert assertions

Похожие вопросы:

score 3 · Answer 1

, Чего необходимо придерживаться, являются образцом , Расположение, закон, Утверждает (и затем закончите тест). В вашем случае вся договоренность находится в TestFixtureSetUp, как протестированное действие. Я перестроил бы это немного, это может стать громоздким, когда у вас есть больше тестов. Как примечания Докеров, нужно избежать тяжелых тестовых установок, они могут стать проблемами - они "едины" через все тесты в классе и так могут стать более тяжелыми, чем большинству тестов нужно.

, Если вы испытываете желание продолжить к другому последующему действию и затем больше утверждает, поместите это в отдельный тест.

у меня нет проблемы с помещением, несколько утверждают в том же тесте, пока они способствуют тестированию того же самого (т.е. часть того же "Логического Утверждения"). В этом случае любое количество утверждает на содержании этого. Результат. Данные были бы в порядке мной - они все осмотрят то же значение результата. Ваш Get_UsingStaticSettings_HasData делает это очень ясно. Лучше использовать уникальное сообщение об отказе на каждом, утверждают так, чтобы было легче сказать, которые утверждают отказавший.

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

В сводке
* Делают одно действие за тест
* После действия, используйте, поскольку многие имели отношение, утверждает, поскольку необходимо протестировать одну вещь
* Конец тест там.

score 15 · Answer 2

Наличие нескольких утверждений в том же тесте может привести к утверждению Roulette , поэтому это что-то, что вы всегда должны быть осторожны.

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

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

score 2 · Answer 3

Вы можете использовать Oapt - Надстройка NUnit для запуска одного утверждения для каждого теста:

[TestFixture]
public class GridControllerTests
{
  [TestCase, ForEachAssert]
  public void Get_UsingStaticSettings_Assign()
  {
      var dataRepository = new XmlRepository("test.xml");
      var settingsRepository = new StaticViewSettingsRepository();
      var controller = new GridController(dataRepository, settingsRepository);

      var result = controller.Get("A1");

      AssertOne.From(
        () => Assert.That(this.Result,Is.Not.Null),
        () => Assert.That(this.Result.Data,Is.Not.Null),
        () => Assert.That(this.Result.Data.Count,Is.GreaterThan(0)),
        () => Assert.That(this.Result.State.ViewId,Is.EqualTo(RequestedViewId)),
        () => Assert.That(this.Result.State.CurrentPage, Is.EqualTo(1)));
  }
}

Это создаст 5 различных тестовых случаев, по одному для каждого утверждения.

score 0 · Answer 4

Я склонен помещать утверждения отдельно, только если они ценны сами по себе. Если мне нужно утверждение само по себе, я делаю пользовательское утверждение:

AssertThatMyObjectMatches(field1, field2, field3, field4, myObject);

Иногда, однако, мне нравится иметь более одного примера в тесте. Я делаю это, когда половина поведения не имеет ценности без другой половины.

Assert.True(list.IsEmpty());

list.Add(new Thing());
Assert.False(list.IsEmpty());

Другие, включая большую часть сообщества Ruby, имеют другое мнение на этот счет. В первую очередь, это связано с записью в блоге Дейва Астелса, вот здесь:

http://www.artima.com/weblogs/viewpost.jsp?thread=35578

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

Что бы ни работало для вас и вашей команды, это, вероятно, правильный путь. Я склонен делать то, что кажется простым и легко изменяемым, чтобы быть правильным позже, когда у меня будет лучшее представление о том, что такое правильное решение. В более сложные примеры я также добавляю много комментариев Given / When / Then на уровне модулей, и разбиваю класс, если он становится слишком сложным для понимания.

Причина написания тестов таким образом не в том, чтобы вы могли отловить то, что сломалось. Она заключается в том, чтобы помочь людям понять код и изменить его, не ломая вещи в первую очередь.