Для чего тесты пишут?

Question

[0x80070005]

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

Пример теста из интернета:

describe('React Portal', () => {
  it('Должен отображать предоставленный контент в существующей ноде', async () => {
    const containerId = 'container-id';
    
    render(
      <>
        <div id={containerId} data-testid='some-test-id'></div>
        <Portal id={containerId}>
          some text
        </Portal>
      </>
    );

    const container = screen.getByTestId('some-test-id');
    expect(container).toContainHTML('some text');
  });
  it('Должен прокидывать ошибку, если не существует контейнера для рендеринга портала', async () => {
    const containerId = 'container-id';

    expect(() => render(
      <Portal id={containerId}>
        some text
      </Portal>
    ))
    .toThrow(PORTAL_ERROR_MSG);
  }); 
});

Comments

[StreetWanderer]

Погуглите "регрессия".

[0x80070005]

StreetWanderer, ну, это же тоже самое что я написал «проверить работу». Но почему нельзя просто проверить это без теста? :)

[StreetWanderer]

0x80070005, а зачем автоформатирование в IDE? Можно же вручную отступы и переносы строк сделать.

[0x80070005]

StreetWanderer, ну, тут понятно. А вот про тесты вообще мне ничего не понятно :)

[StreetWanderer]

0x80070005, и там и там монотонная ручная работа.

[Василий Банников]

А в чем проблема проверить тогда без этого теста?

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

Answer 1

[Василий Дёмин]

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

Comments

[0x80070005]

Блин, надо будет как-то попробовать. До сих пор не могу понять :)

[0x80070005]

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

[Василий Дёмин]

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

[Василий Дёмин]

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

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

[0x80070005]

Василий Дёмин, а для малых проектов это имеет смысл?

[Василий Дёмин]

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

[0x80070005]

Василий Дёмин, понял, спасибо! Но я все равно попробую эти тесты сделать, может так пойму

[Refguser]

0x80070005, начни с изучения понятия "чеклист".

[0x80070005]

Refguser, хорошо)

[Михаил Ливач]

0x80070005,

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

Вот Вам пример из практики ( не Реакт, но тоже JS): на нескольких страницах показывается попап. Код попапа скопирован с другого проекта. Один разработчик посмотрел, что на тех страницах, которые ему отдали на интеграцию, попап без заголовка, а в коде заголовок первым параметром, неудобно. "Попап заимствован, а тут заголовок не нужен" - подумал он, и выкинул заголовок из аргументов попапа, и стало ему хорошо.
Вот только на совсем другой странице, сданной пару недель назад, на попапе стал красоваться undefined...

Answer 2

[Refguser]

А в чем проблема проверить тогда без этого теста?

Проверить - это уже тест. И ты имеешь ввиду ручной, а спрашиваешь "зачем пишут". Т.е. суть вопроса: "зачем пишут автотесты".
Так вот, приближённая аналогия этого вопроса - "в чём проблема дойти из Москвы до Магадана пешком, зачем автомобили и самолёты?"

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

Итого: автотесты снижают стоимость и сокращают время.

Answer 3

[VoidVolker]

Да, конечно можно проверить работу каждой фичи и функции ручками. Это если у тебя три-пять фич/функций, ну десяток еще можно, а изменения - раз в неделю. А если это надо делать на каждый коммит? Десять коммитов в день? А как проверять, если там 100 экранов, на каждом экране по сотне графических элементов, у которых по пять состояний в различных вариантах, два десятка эндпоинтов в бэкэнде, а в коде паутина из 10-100к функций и хрен знает сколько зависимостей? Итого 100 x 100 x 5 x 20 - уже миллион вариантов. Ой, а у нас там еще есть отдельная админка для этого вот всего, биллинг, мониторинг, отчеты, интеграция с тремя десятками платёжных систем и бакнов, почта, интеграции с мессенджерами, кэширование, резервирование, бэкапы и еще пара сотен зависимостей и интеграций с другими системами. Сколько месяцев или даже лет ручного труда потребуется для ручной проверки работы такого проекта в каждом коммите за время работы команды из десяти разработчиков в течении хотя бы одной недели?

Возьмём для примера обычный виндовый калькулятор: 4 варианта - 40 элементов интерфейса только в одном только обычном варианте, в статистике - примерно 50, в инженерном чуть больше сотни, в режиме программиста - все две сотни. И у каждого элемента в среднем от одного до десяти состояний, плюс еще связи с другими элементами, а так же разное поведение, зависящее от других элементов. И работу каждого элемента надо проверить с учетом всех возможных вариантов его работы. Сотни и тысячи фич/функций, десятки и, вероятно даже сотни, тысяч вариантов. Да, конечно, большая часть всего этого перекрывается более высокоуровневыми тестами и переиспользованием уже написанного кода (что, кстати, как раз и создаёт все эти зависимости) и тестировать под сто раз одно и то же нет необходимости. Но вот так, вручную, без конкретного списка конкертных фич и автоматизации - как проверить правильность работы хотя бы вот такого обычного калькулятора?

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

А еще есть такая методика, как TDD: разработка через тестирование - сначала создаётся тест на фичу, а уже только потом создаётся сама фича.