Pull to refresh

Comments 9

PinnedPinned comments

С версии 1.22 в циклах for - range под каждую итерацию инициируется отдельная переменная, в более старых версиях инициировалась одна переменная для всего цикла.
https://tip.golang.org/doc/go1.22

Многие пишут юнит-тесты, но не все знают, как писать функциональные.

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

Функциональное тестирование проверяет внешний слой программы - её интерфейс взаимодейстия. Юнит тесты проверяют внутренние слои программы так, как если бы они являлись внешним интерфейсом. Т.е. юнит тест это и есть функциональный тест, который пишется для внуреннего слоя.

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

Пока что у нас есть только 1: “local.yaml”, необходимо создать второй: “local_tests.yaml”. В нем оставим все те же настройки, кроме одной - timeout. Изменим ее значение с 4s на 10h

Уместно ли такое утверждение для автотестов?
Если подобное работает локально и не расписанию (в CI/CD по шедулеру), то я еще понимаю такое растягивание таймаутов, но при использовании подобного в прогонах не аффектим ли мы общую статистику выполнения автотестов?

А если говорить про кейсы то деление на 0 наверное то что хотелось бы увидеть (Не знаю умеет ли go в генерацию 0.0 функцией generateRandomFloat)

А если говорить про кейсы то деление на 0 наверное то что хотелось бы увидеть (Не знаю умеет ли go в генерацию 0.0 функцией generateRandomFloat)

А вот этот случай я не просчитал) Да, если запустить программу и поделить на ноль, то ошибка возникнет но не так, как нам нужно(не будет json-ответа с ошибкой). Спасибо, что учли

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

Ну по моему опыту написанию автотестов я вам точно скажу что такой подход bad practice) Лучше делать явные ожидания, и читабельность выше и производительность хорошая

Изменим ее значение с 4s на 10h(но при автотестировании такого лучше не делать).

Немного исправил

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

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, это действие утратило необходимость или это неточность в статье?

Думаю, что нет, не утратило. Спасибо на указание, исправил

С версии 1.22 в циклах for - range под каждую итерацию инициируется отдельная переменная, в более старых версиях инициировалась одна переменная для всего цикла.
https://tip.golang.org/doc/go1.22

Sign up to leave a comment.

Articles