Конкретный пример. Есть экспортный шаг, который выполняет некое действие. Разработчик хорошо доработал код, все работает, бизнес-логика выдержана по тз. Однако данный шаг (или шаги) используется в куче тестов. И он об этом не подозревал (как и я, так как тестов много). Теперь я вынужден или пойти сам адаптировать этот шаг под новые условия или обязать его. И что возразить на замечание "у меня все работает, в проде тоже, тесты ваши - это внешний код, вот сами его и адаптируйте"?

Обратная совместимость нарушена скорее всего, раз старый шаг перестал работать

Тесты были правильные, а стали нет, после появления новой сущности

Давай конкретнее

Вот то, что "тесты - это внешний код" и надо выбить из его головы

Окей. Перед проведением документа есть ряд проверок. Экспортный шаг в процессе выполнения подаёт на вход проверкам нужные параметры. Появилась новая проверка, тест ничего про неё не знает, ничего на вход не подаёт - шаг падает

Давайте угадаю.. у кого-то под "шагом" подразумевается пара десятков строк сильно связанного кода. При нормальной архитектуре этих проблем не будет.

Пример шага см выше, вот я очень конкретный пример описал сейчас

Новая проверка обязательная что ли? Обычно любую проверку надо делать так: https://t.me/ssl1c/48904

Обязательная, да. Такая логика, к примеру

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

Да даже если и не обязательная - все равно надо пойти и добавить обход этой проверки по доп свойству в шаг

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

Конечно логично))) я ж не про это спросил. Я спросил, КТО будет это делать - автор ли изменений, или автор тестов

Это у вас "как обычно", а в большинстве серой массы хомяков это "хай-левл". Не сломал проведение, и то хорошо уже

Это организационный вопрос, оба варианта приемлемы, ибо не все участвуют в тестировании, это может быть вообще внешний подрядчик и если с ним не оговорено это было заранее (что должна быть обратная совместимость), то он пошлет автотестировщиков и будет прав

Короч, вы все в один голос говорите, что автор изменений и за актуальность тестов отвечает. Я то согласен, осталось аргументы подобрать и закрепить это законодательно, так сказать

Именно

Пока вижу так - штатный разраб сам актуализирует тесты, за внешними разрабами придётся штатникам

Я склоняюсь, что за тесты автор изменений точно отвечать не должен, ибо не он составитель тестовых сценариев, т.е. не владеет их целью и их контекстом