blp>Есть ряд вопросов к тем, у кого есть подобный опыт внедрения какой-то новой практики в команде, которая работает по принципу "копаем, как можем, когда надо можем копать быстрее, нанимаем больше копателей, об эскавторах не думали, ибо слишком сложно"

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

Если всё-таки станете внедрять, стоит начать с проблемы, которую тестирование призвано решить. Например у вас 90% пофикшенных багов переоткрываются через каждые полтора релиза. Или там производительность ключевых фич непредсказуемым образом деградирует и выясняется это от юзеров. В зависимости от проблемы внедрять вы захотите совершенно разное тестирование. Вот вы например пишете конкретно юнит-тестирование (типа "1 класс — 1 тест"). Почему не интеграционные тесты например (типа "одна операция API — вся цепочка от фасада до БД — 1 тест")?