Comments 9
Многие пишут юнит-тесты, но не все знают, как писать функциональные.
Это как сказать, что многие водят автомобили чёрного цвета, но не все знают, как управлять синими автомобилями.
Функциональное тестирование проверяет внешний слой программы - её интерфейс взаимодейстия. Юнит тесты проверяют внутренние слои программы так, как если бы они являлись внешним интерфейсом. Т.е. юнит тест это и есть функциональный тест, который пишется для внуреннего слоя.
Понятное дело, что эти вещи схожи. Но аналогию про автомобили черного и синего цвета я считаю не уместной. При юнит-тестировании Вы вызываете функцию и проверяете ее на правильность. Функциональное тестирование - когда программа, не зная, что ее тестируют, выдает результаты, которые она бы выдала при реальном использовании. Для того, чтобы понять, каким образом это вообще работает и написана эта статья.
Пока что у нас есть только 1: “local.yaml”, необходимо создать второй: “local_tests.yaml”. В нем оставим все те же настройки, кроме одной - timeout. Изменим ее значение с 4s на 10h
Уместно ли такое утверждение для автотестов?
Если подобное работает локально и не расписанию (в CI/CD по шедулеру), то я еще понимаю такое растягивание таймаутов, но при использовании подобного в прогонах не аффектим ли мы общую статистику выполнения автотестов?
А если говорить про кейсы то деление на 0 наверное то что хотелось бы увидеть (Не знаю умеет ли go в генерацию 0.0 функцией generateRandomFloat
)
А если говорить про кейсы то деление на 0 наверное то что хотелось бы увидеть (Не знаю умеет ли go в генерацию 0.0 функцией
generateRandomFloat
)
А вот этот случай я не просчитал) Да, если запустить программу и поделить на ноль, то ошибка возникнет но не так, как нам нужно(не будет json-ответа с ошибкой). Спасибо, что учли
Что насчет автотестов - не знаю, скорее всего нет, не уместно. Я писал при условии, что данное тестирование будет проводиться только при запуске программы. Почему мы должны портить статистику выполнения?
Разработчики языка в своих примерах пишут, что надо переопределять переменную цикла
func TestGroupedParallel(t *testing.T) {
for _, tc := range testCases {
tc := tc // capture range variable
t.Run(tc.Name, func(t *testing.T) {
t.Parallel()
if got := foo(tc.in); got != tc.out {
t.Errorf("got %v; want %v", got, tc.out)
}
...
})
}
}
Однако в статье этого действия нет. Начиная с какой то версии go, это действие утратило необходимость или это неточность в статье?
Написание функционального тестирования в Go