Отличный вопрос, ответ на который заслуживает отдельного поста. Начать стоит с того, что тестирование и архитектурный надзор отличаются по подходам и если тянуть весь накопленный в тестировании десятилетиями багаж знаний, то это может увести в неверном направлении. У фитнес-функций отличается подход, отличается, если угодно mindset. То есть нужен свой понятийный аппарат, который выступит фильтром для того, что взять из тестирования, а что определить уникально. Несколько примеров. ▪️Тесты направлены на корректность, а фитнес-функции на целевой уровень. Условие «время отклика не должен превышать 200мс» с точки зрения теста: ✅ 199мс ⛔️ 201мс С точки зрения фитнес-функции: ⚠️ Вчера 50мс, сегодня 150мс - формально ✅, но архитектура деградирует. ▪️Компромиссы. Тут граница тоньше. В архитектуре мы можем выбирать, какое из двух не идеальных решений лучше через веса: (1/latency)*0.7+(1/cost)*0.3 Здесь показан компромисс между быстрым и дорогим и медленным, но дешевым. ▪️Тесты проверяют состояние и поведение, фитнес-функции еще и структуру: слой UI не должен напрямую обращаться к слою данных. ▪️Перспектива (или иначе - горизонт) - прошли тесты, - деплоим. Фитнес-функции оценивают еще и архитектурный дрейф. Добавили вызов слоя данных из слоя UI - функционально все в порядке, но фитнес-функция должна сигнализировать, что вот здесь появился архитектурный долг, соответственно поддерживаемость системы немного снизилась. А еще это элемент легитимизации - тесты вроде как пишут тестировщики (берем широко), а тут раз и выводим архитектурные тесты в отдельную дисциплину управления развитием (эволюцией системы). PS: Пока это писал, сам заметил интересный тренд. Несмотря на то, что общая теория систем появилась давно, мы в индустрии какое-то время двигались в сторону разделения обязанностей - код написан -> тесты выполнены -> код задеплоен. DevOps первым ушел от этой парадигмы, сведя критерии готовности для всего жизненного цикла к одному (единому) требованию - код работает в проде (убрав промежуточные статусы). Концепции эволюционной архитектуры, фитнес-функции и архитектура как код добавили архитектуру в общий pipeline поставки, сделав архитектуру частью продукта и применив к ней те же требования, но с описанными выше особенностями.