Здравствуйте, Буравчик, Вы писали:

Б>Свой собственный тестовый фреймворк? Зачем?

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

Б>По-моему, если проект разрастется до сотен тысяч строк, то без тестов проект развалится на любом языке. А если тесты есть, то и на питоне можно жить.

Так это само по себе — тестовый проект. Еще и к нему тесты писать — я не решусь предложить.
Я работал с подобными тестовыми фреймворками на C# и на TCL. В случае с TCL там размер команды был менее 10 человек и таких проблем еще не возникало. А в случае с C# помогала именно компиляция. Кода там было много, разработчиков много, но физически невозможно было раскорячить всю систему одним неосторожным коммитом.

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

Б>Для питона можно (нужно) прописывать типы. В этом случае статический анализатор выявит большую часть ошибок типов.

Надо посмотреть в эту сторону.