Комментарии 3
Кратко: E2E тесты это хорошо и удобно, но непрактично долго и всё равно ломаются при доработках интерфейса (что, мягко говоря, не менее важно, чем рефакторинг), а потому вовсе не панацея.
Спасибо, КО!
Потому народ и ищет компромиссы и мирится с многочисленными проблемами промежуточных вариантов...
Защита от регресса зависит от позиции границы. Если она располагается близко к деталям реализации, то итоговые тесты верифицируют крупный сценарий
Мне кажется, что здесь стоило упомянуть про разницу между верификацией и валидацией.
Верификация это проверка артефактов на соответствие формальным требованиям и стандартам. Она не требует запускать программу. На практике это разные виды анализа: документации, спецификаций, дизайна, статический анализ кода (проверка типов как пример), код ревью, ревью тестов (кстати), SAST, SCA и т.п. Может быть частью различных аудитов.
Валидация проверяет насколько софт удовлетворяет потребностям пользователей. Здесь код запускается, а результаты не в последнюю очередь зависят от окружения.
Тестирование по смыслу ближе к валидации - оно обычно принимает форму испытаний приложения или его частей в контролируемых (изолированных, лабораторных) условиях. Но довольно часто используется и как зонтичный термин, охватывающий различные практики QA.
Что и на каких уровнях стоит верифицировать или валидировать зависит от целей. Простые как спички приложения можно проверять в сборе в формате e2e. Но софт со сложностью как у звездолета вы чаще будете проверять по частям. Вряд-ли проверку изменений в работе какого-нибудь сумматора стоит откладывать на месяцы до момента UAT, когда такая конструкция оторвётся от земли. Аргумент: за то нам не пришлось писать и переписывать на него такие хрупкие тесты - это поржать/всплакнуть если/когда что-то пойдет не так).
Тестируемая архитектура. Часть 3: граница тестирования