Почему юнит-тесты должны тестировать только одно?

Тестирование только одного элемента позволит выделить его и доказать, работает оно или нет. В этом заключается идея модульного тестирования. Нет ничего плохого в тестах, которые проверяют более одного объекта, но это обычно называется интеграционным тестированием. У них обоих есть достоинства, в зависимости от контекста.

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

Обновление: я прочитал эту статью и связанные статьи, и я должен сказать, я потрясен: https://techbeacon.com/app-dev-testing/no-1-unit-testing-best-practice-stop-doing-it

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

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

[Редактировать:] Хорошо, скажем, это образец метода тестирования:

[TestMethod]
public void TestSomething() {
  // Test condition A
  // Test condition B
  // Test condition C
  // Test condition D
}

Если ваш тест на условие A не прошел, то B, C и D также окажутся неудачными и не принесут вам никакой пользы. Что, если бы изменение вашего кода также привело бы к сбою C? Если бы вы разделили их на 4 отдельных теста, вы бы это знали.

Если вы тестируете более одного объекта, и первое, что вы тестируете, терпит неудачу, вы не узнаете, пройдут ли последующие объекты, которые вы тестируете, или нет. Это легче исправить, когда вы знаете все, что выйдет из строя.

Хааа ... юнит-тесты.

Если зайти слишком далеко с любыми «директивами», он быстро станет непригодным для использования.

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

Является

@Test
public void checkNullInputFirstArgument(){...}
@Test
public void checkNullInputSecondArgument(){...}
@Test
public void checkOverInputFirstArgument(){...}
...

лучше чем

@Test
public void testLimitConditions(){...}

На мой взгляд, это вопрос вкуса, а не хорошей практики. Я лично предпочитаю последнее.

Но

@Test
public void doesWork(){...}

на самом деле "директива" хочет, чтобы вы избегали любой ценой и что быстрее всего истощает мое рассудок.

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

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

Мои 2 цента.

Я собираюсь рискнуть и сказать, что совет «только проверяйте одно» на самом деле не так полезен, как его иногда воображают.

Иногда тесты требуют определенной настройки. Иногда для их настройки может потребоваться определенное количество время (в реальном мире). Часто вы можете протестировать два действия за один раз.

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

Против: если действие либо завершится неудачно, вы получите тот же результат: тот же тест не удастся. У вас будет меньше информации о том, в чем проблема, чем если бы вы выполняли только одно действие в каждом из двух тестов.

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

Немного другой «минус» здесь состоит в том, что он прерывает цикл «написать новый тест, пройти, рефакторинг». Я рассматриваю это как цикл идеальный, но тот, который не всегда отражает реальность. Иногда просто более прагматично добавить дополнительное действие и проверку (или, возможно, просто еще одну проверку к существующему действию) в текущем тесте, чем создавать новый.

GLib, но, надеюсь, все еще полезный, ответ таков: unit = one. Если вы тестируете более одного объекта, значит, вы не тестируете модуль.

Используя разработку через тестирование, вы должны сначала написать свои тесты, а затем написать код для прохождения теста. Если ваши тесты сфокусированы, это упрощает написание кода для прохождения теста.

Например, у меня может быть метод, принимающий параметр. Одна из вещей, о которой я мог бы подумать в первую очередь, - что должно произойти, если параметр равен нулю? Он должен выбросить исключение ArgumentNull (я думаю). Поэтому я пишу тест, который проверяет, возникает ли это исключение, когда я передаю нулевой аргумент. Запустите тест. Хорошо, это выдает NotImplementedException. Я исправляю это, изменяя код, чтобы генерировать исключение ArgumentNull. Запустите мой тест, он прошел. Тогда я думаю, что будет, если он слишком маленький или слишком большой? Ах, это два теста. Сначала я напишу слишком маленький случай.

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

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

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

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

Наличие тестов, которые проверяют только одно, упрощает поиск и устранение неисправностей. Это не значит, что у вас не должно быть тестов, которые тестируют несколько вещей, или нескольких тестов, которые используют одну и ту же настройку / разборку.

Вот наглядный пример. Допустим, у вас есть класс стека с запросами:

• getSize
• пусто
• getTop

и методы для изменения стека

• push (объект)
• поп ()

Теперь рассмотрим следующий тестовый пример (в этом примере я использую псевдокод Python).

class TestCase():
    def setup():
        self.stack = new Stack()
    def test():
        stack.push(1)
        stack.push(2)
        stack.pop()
        assert stack.top() == 1, "top() isn't showing correct object"
        assert stack.getSize() == 1, "getSize() call failed"

Из этого тестового примера вы можете определить, что что-то не так, но не изолировано ли это от реализаций push() или pop() или запросов, возвращающих значения: top() и getSize().

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

def test_size():
    assert stack.getSize() == 0
    assert stack.isEmpty()

def test_push():
    self.stack.push(1)
    assert stack.top() == 1, "top returns wrong object after push"
    assert stack.getSize() == 1, "getSize wrong after push"

def test_pop():
    stack.push(1)
    stack.pop()
    assert stack.getSize() == 0, "getSize wrong after push"

Что касается разработки через тестирование. Я лично пишу более крупные «функциональные тесты», которые заканчиваются сначала тестированием нескольких методов, а затем создают модульные тесты, когда я начинаю реализовывать отдельные части.

Другой способ взглянуть на это - это модульные тесты, проверяющие контракт каждого отдельного метода, в то время как более крупные тесты проверяют контракт, которому должны следовать объекты и система в целом.

Я все еще использую три вызова методов в test_push, однако и top(), и getSize() - это запросы, которые проверяются отдельными тестовыми методами.

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

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

namespace Tests.Integration
{
  [TestFixture]
  public class FeeMessageTest
  {
    [Test]
    public void ShouldHaveCorrectValues
    {
      var fees = CallSlowRunningFeeService();
      Assert.AreEqual(6.50m, fees.ConvenienceFee);
      Assert.AreEqual(2.95m, fees.CreditCardFee);
      Assert.AreEqual(59.95m, fees.ChangeFee);
    }
  }
}

В то же время мне очень хотелось увидеть все мои утверждения, которые потерпели неудачу, а не только первое. Я ожидал, что все они проиграют, и мне нужно было знать, какие суммы я действительно получаю. Но стандартный [SetUp] с каждым разделенным тестом вызовет 3 вызова медленной службы. Внезапно я вспомнил статью, в которой говорилось, что в использовании «нетрадиционных» тестовых конструкций скрыта половина преимуществ модульного тестирования. (Я думаю, что это был пост Джереми Миллера, но сейчас не могу его найти.) Внезапно [TestFixtureSetUp] всплыл в памяти, и я понял, что могу сделать один вызов службы, но все же иметь отдельные выразительные методы тестирования.

namespace Tests.Integration
{
  [TestFixture]
  public class FeeMessageTest
  {
    Fees fees;
    [TestFixtureSetUp]
    public void FetchFeesMessageFromService()
    {
      fees = CallSlowRunningFeeService();
    }

    [Test]
    public void ShouldHaveCorrectConvenienceFee()
    {
      Assert.AreEqual(6.50m, fees.ConvenienceFee);
    }

    [Test]
    public void ShouldHaveCorrectCreditCardFee()
    {
      Assert.AreEqual(2.95m, fees.CreditCardFee);
    }

    [Test]
    public void ShouldHaveCorrectChangeFee()
    {
      Assert.AreEqual(59.95m, fees.ChangeFee);
    }
  }
}

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

Коллега также отметил, что это немного похоже на specunit.net Скотта Беллвэра: http://code.google.com/p/specunit-net/

Другой практический недостаток очень детализированного модульного тестирования заключается в том, что оно нарушает СУХОЙ принцип. Я работал над проектами, в которых правилом было то, что каждый общедоступный метод класса должен иметь модульный тест ([TestMethod]). Очевидно, это добавляло некоторые накладные расходы каждый раз, когда вы создавали общедоступный метод, но реальная проблема заключалась в том, что это добавляло некоторое «трение» к рефакторингу.

Это похоже на документацию уровня метода, это приятно иметь, но это еще одна вещь, которую нужно поддерживать, и это делает изменение сигнатуры или имени метода немного более громоздким и замедляет «рефакторинг зубной нити» (как описано в «Инструменты рефакторинга: соответствие назначению» Эмерсона Мерфи-Хилла и Эндрю П. Блэк. PDF, 1,3 МБ).

Как и в большинстве случаев в дизайне, существует компромисс, который не отражает фраза «тест должен проверять только одно».

Подумайте о постройке машины. Если бы вы применили свою теорию о простом тестировании больших вещей, то почему бы не провести тест, чтобы проехать на машине по пустыне. Это ломается. Хорошо, скажи мне, в чем проблема. Вы не можете. Это тест сценария.

Функциональная проверка может заключаться в запуске двигателя. Это не удается. Но это могло быть по ряду причин. Вы все еще не могли сказать мне, что именно вызвало проблему. Но мы приближаемся.

Модульный тест является более конкретным и сначала определит, где код неисправен, но он также (при правильном TDD) поможет спроектировать ваш код в виде четких модульных фрагментов.

Кто-то упомянул об использовании трассировки стека. Забудь это. Это второе средство. Просматривать трассировку стека или использовать отладку сложно и может занять много времени. Особенно на больших системах и сложных ошибках.

Хорошие характеристики юнит-теста:

• Быстро (миллисекунды)
• Независимый. Это не зависит от других тестов и не зависит от них.
• Прозрачный. Он не должен быть раздутым или содержать огромное количество настроек.

Когда тест не проходит, есть три варианта:

1. Реализация не работает и требует исправления.
2. Тест не работает, и его нужно исправить.
3. Тест больше не нужен, и его следует удалить.

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

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

Вот как это может выглядеть (с GoSpec), когда каждый тест проверяет только одно:

func StackSpec(c gospec.Context) {
  stack := NewStack()

  c.Specify("An empty stack", func() {

    c.Specify("is empty", func() {
      c.Then(stack).Should.Be(stack.Empty())
    })
    c.Specify("After a push, the stack is no longer empty", func() {
      stack.Push("foo")
      c.Then(stack).ShouldNot.Be(stack.Empty())
    })
  })

  c.Specify("When objects have been pushed onto a stack", func() {
    stack.Push("one")
    stack.Push("two")

    c.Specify("the object pushed last is popped first", func() {
      x := stack.Pop()
      c.Then(x).Should.Equal("two")
    })
    c.Specify("the object pushed first is popped last", func() {
      stack.Pop()
      x := stack.Pop()
      c.Then(x).Should.Equal("one")
    })
    c.Specify("After popping all objects, the stack is empty", func() {
      stack.Pop()
      stack.Pop()
      c.Then(stack).Should.Be(stack.Empty())
    })
  })
}

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

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

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

The real question is why make a test or more for all methods as few tests that cover many methods is simpler.

Что ж, чтобы, когда какой-то тест не прошел, вы знали, какой метод не работает.

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

An example: A list class. Why should I make separate tests for addition and removal? A one test that first adds then removes sounds simpler.

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

Отказ от ответственности: на этот ответ сильно повлияла книга «Тестовые шаблоны xUnit».

Тестирование только одного предмета в каждом тесте - один из самых основных принципов, который дает следующие преимущества:

• Локализация дефекта: Если тест не прошел, вы сразу узнаете, почему он не прошел (в идеале без дальнейшего устранения неполадок, если вы хорошо поработали с используемыми утверждениями).
• Тест как спецификация: тесты служат не только в качестве подстраховки, но и могут быть легко использованы в качестве спецификации / документации. Например, разработчик должен иметь возможность читать модульные тесты отдельного компонента и понимать его API / контракт, без необходимости читать реализацию (используя преимущества инкапсуляции).
• Невозможность TDD: TDD основан на наличии фрагментов функциональности небольшого размера и выполнении последовательных итераций (написание неудачного теста, написание кода, проверка успешности теста). Этот процесс сильно прерывается, если тест должен проверить несколько вещей.
• Отсутствие побочных эффектов: В некоторой степени связано с первым, но когда тест проверяет несколько вещей, более вероятно, что он будет привязан и к другим тестам. Таким образом, для этих тестов может потребоваться общая тестовая оснастка, а это значит, что на один будет влиять другой. Итак, в конечном итоге у вас может быть сбой теста, но на самом деле другой тест вызвал сбой, например путем изменения данных приспособления.

Я вижу только одну причину, по которой вам может быть полезно иметь тест, который проверяет несколько вещей, но на самом деле это следует рассматривать как запах кода:

• Оптимизация производительности: в некоторых случаях ваши тесты не выполняются только в памяти, но также зависят от постоянного хранилища (например, баз данных). В некоторых из этих случаев наличие тестовой проверки нескольких вещей может помочь уменьшить количество обращений к диску, тем самым уменьшив время выполнения. Однако в идеале модульные тесты должны выполняться только в памяти, поэтому, если вы наткнетесь на такой случай, вам следует еще раз подумать, идете ли вы по неправильному пути. Все постоянные зависимости должны быть заменены фиктивными объектами в модульных тестах. Сквозная функциональность должна быть охвачена другим набором интеграционных тестов. Таким образом, вам больше не нужно заботиться о времени выполнения, поскольку интеграционные тесты обычно выполняются конвейерами сборки, а не разработчиками, поэтому немного большее время выполнения почти не влияет на эффективность жизненного цикла разработки программного обеспечения.