Мне кажется, это совершенно разные системные уровни. Бизнес-метрики говорят о надсистеме (пользователи, выполняющие сценарии предметной области). Интеграционные тесты - о самой системе и её подсистемах (где что внутри ломается, сбоит, тормозит). Как обычно, эти уровни существуют одновременно, не смешиваясь. И я бы не стал ни заменять одни метрики другими, ни смешивать их.

интересно, почему именно как мониторинг?
вам нужно постоянно мониторить результат тестов, даже если ничего не изменилось на стенде (не было деплоя кода или изменений окружения)?

Просто "интеграционные" тесты - по определению предполагают определённый уровень изоляции, чем отличаются от acceptance и e2e. Я не очень понимаю, как изолировать фрагменты системы в проде, и какую реальную пользу такое тестирование может принести.

Например компонент "шлюз к эквайеру". Его вполне реально тестировать изолировано (но дорого, хотя если делать только одну фазу...

В свою очередь, e2e не может покрыть всё разнообразие юзкейсов, тесты будут зелёные, а система сломана. Это хуже, как по мне.

Ну так надо совмещать, конечно )

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

Может быть тогда тестировать не шлюз, а самого эквайера? Я не спец в домене, но что такое может поломаться в процессе эксплуатации шлюза, прошедшего свои тесты перед выкаткой? За исключением очевидных вещей типа переполнения памяти/диска/whatever?

ну так и мониторьте прохождение реальных данных в реальной среде

зачем специально тесты гонять?

Ну, так в этом и задача - тестировать эквайера через шлюз (так как важно - именно работоспособность шлюза с эквайером)

А, в смысле речь об интеграционном тестировании компонентов за пределами нашей досягаемости. Типа NTP-серверов, условно. Но я всё равно считаю, что тестировать надо свои компоненты изолированно (MockNTPServer), а не зависящие от нас вещи мониторить. Иначе слишком много энтропии.

Не, моки - это плохая идея почти всегда )

Хороший аргумент. Подумаю как сформулировать - отвечу

я бы понял вас, если бы в на инцидентах на бою набирали бы статистику, постоянно пополняли тест-кейсы, например "пришел номер карты 0000-0000 - у нас всё упало, а падать не должно, должно быть внятное сообщение об ошибке" и эти тест-кейсы гоняли бы при развертывании

но зачем гонять одни и те же тест-кейсы на одном и том же коде и том же самом окружении?

Всё генерализации - ложны.

Не является ли данное утверждение генерализацией? 🤔

Потому у меня и сказано - _почти_ всегда )

Кого почитать?