воскресенье, 17 марта 2019 г.

Go Code Review Comments: Полезные падения тестов

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

if got != tt.want {
    t.Errorf("Foo(%q) = %d; want %d", tt.in, got, tt.want) 
    // или Fatalf, 
    // если тест не может тестировать что-либо далее 
    // этой точки
}

Обратите внимание, на порядок актуальный != ожидаемый, и сообщение также использует этот порядок. Некоторые тестовые среды рекомендуют записывать их в обратном порядке: 0 != x, «ожидаемый 0, полученный x» и так далее. Go не использует такой подход.

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

Еще одна распространенная техника устранения неоднозначности неудачных тестов - это использование тестового помощника (test helper) с разными вводными данными - оберните каждого вызывающего различной функцией TestFoo, таким образом тест будет завершаться неудачно с разным именем:

func TestSingleValue(t *testing.T) { testHelper(t, []int{80}) }
func TestNoValues(t *testing.T)    { testHelper(t, []int{}) }

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


Читайте также:


Комментариев нет:

Отправить комментарий