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

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

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

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

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

Хорошие характеристики модульного теста:

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

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

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

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

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

Вот как это может выглядеть (с 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())
    })
  })
}