Comments 4
Вы переоцениваете тесты.
Проблемы с масштабируемостью крайне опосредованно зависят от покрытия. Основные проблемы — избыточная связность, отсутствие интерфейсных границ между подсистемами, заведомая неготовность к параллелизации и отчуждению вычислений.
Тесты в принципе помогут не сильно, а если это не property-based тесты на умных моках, а просто какая-нибудь фигня типа юнитов и аксептанса — то и вовсе скорее навредят при масштабировании.
О чём статья? Какое то повторение + бесполезные примеры.
Это вообще перл:
Но это должно происходить только как следствие наличия у вас мгновенной обратной связи о корректности работы, а не из-за заранее продуманной архитектуры.
Резюмирую: автор говорит "пишите сразу ужасную лапшу, даже не пытайтесь сделать хорошо, потом сделайте интегральные тесты сразу на всё, а потом через пару лет пытайтесь это всё распутать"
Подход, очевидно, неприемлемый
Мне показалось, что автор описывает ситуацию распила монолитной системы... Ну, грубо говоря, Ансамбль на ходу переделывается в Энейблер ;-)
Почему тесты, а не следование принципам SOLID?
SOLID же как раз и про то, чтобы сделать так, чтобы не было мучительно больно потом нарастить и/или переделать.
PS Вместе с SOLID тут можно подставить и DRY? KISS и прочие YAGNI.
Как писать по-настоящему масштабируемый код?