Я просто хочу один общий исполняемый файл под обе среды

не выйдет, если посмотреть на локуст, то там надо от его классов наследоваться и писать соотвтетсвенно под него. что может получиться, так это вынести какие-то шаги общие, но не 1 в 1 точно

Спасибо за помощь

изначально подход не верный. нагрузочные скрипты != автотесты или функциональные сценарии

Селением оправдан если у тебя есть железных ресурсов в три раза больше а инструменты нагрузки затратнее писать (например сложные протоколы)

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

ну и от себя скажу, читать огромный py файл, в котором находится все, очень не удобно.

@jigarkhwar привет, тут в примерах указана тайм зона, но используется LocalDateTime у которой  у неё нет, может стоит перевести на ZonedDateTime?

Заведи ишью плз, будем делать глобальный рефакторинг фидеров всех и поправим

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

ну это нерелевантная возможность для нагрузки, а так можно конечно)

Часто там слишком много повторяющихся паттернов

где?

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

Спасибо, наверное, самый полезный ответ

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

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

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

начните следить просто за временем прогона функционального теста

Это не целевая метрика и она ничего не покажет