Набор впервые прогнан: 121 тест, 10 падений — и это утверждения о продукте, а не дрейф

[gHashTag]

Продолжение #1271. Там набор научился компилироваться; теперь он впервые прогнан.

TRIOS_E2E_DISABLE_KEYCHAIN=1 TRIOS_VARIANT=dev swift test
выполнено 121, пропущено 2, падений 10 в четырёх наборах
процесс завершился сигналом 5

Два пропуска — намеренные, это тесты с удалённым предметом (#1271), и они говорят почему.

Падения не дрейф

Это не «тест отстал от API». Это утверждения о поведении, которые никто не мог проверить месяцами:

• ChatFailureTests.testBackgroundPollerStopsAndResumes (:353) — XCTAssertNil не прошёл: BackgroundHealthPoller после остановки не обнулился.
• ChatFailureTests.testDoctorWithModelFlagRejectedWhenEmpty (:315) — /doctor --model с пустым значением разбирается как doctor(model: nil), а ожидался отказ unknown("/doctor --model"). То есть флаг без значения молча принимается.
• ChatFailureTests.testProviderStatusDisablesModelProbe (:213) — при выключенном каталоге провайдера ожидалось unavailable, получено unknown(error: "not configured").

Падают четыре набора: ChatFailureTests, ChatRequestBuilderTests, ChatRequestSizerTests, ConversationEncryptionTests.

Средовое, о чём стоит знать

Без TRIOS_E2E_DISABLE_KEYCHAIN=1 прогон обрывается насмерть: KeychainSymmetricKeyStoreTests даёт Fatal error: Unexpectedly found nil, и всё после него не выполняется вовсе — то есть без этой переменной вы видите не десять падений, а обрубок. С переменной те шесть тестов проходят.

Сигнал 5 на выходе остаётся и с переменной: что-то ещё падает после последнего сообщения.

Что нужно

1. Разобрать десять падений: для каждого решить, ошибка в коде или в ожидании теста. Судя по трём процитированным, минимум два — в коде.
2. Найти источник сигнала 5.
3. Решить, где живёт TRIOS_E2E_DISABLE_KEYCHAIN=1 — если прогон без неё обрывается, она часть контракта, а не заклинание в чужой памяти.
4. Только после этого swift test можно ставить в ворота: сейчас make xctest считает ошибки сборки, а не результаты.

[gHashTag]

Число «121» было обрубком, и обрубком втрое.

Прогон обрывали два смертельных отказа, каждый из которых превращал одно упавшее утверждение в убийство всего процесса:

1. SSETransportTests.swift:32 — fatalError("MockURLProtocol.requestHandler is not set") внутри URLProtocol. requestHandler это общий статик; LocalAuthProviderTests обнуляет его в разборке, запрос в полёте попадает в протокол с пустым обработчиком, и умирает весь прогон. Заменено на отказ запроса: теперь это одно падение в том наборе, который запрос и утёк.

2. Четырнадцать мест вида XCTAssertNotNil(x) и на следующей строке x! — в четырёх файлах. Падение утверждения роняло процесс. Заменено на guard let ... else { XCTFail; return }.

Что это дало

133  до починок      обрыв на fatalError
187  после первой    обрыв на принудительном развороте
483  после второй    обрывов нет

Считано по уникальным Test Case ... started, а не суммированием строк «Executed N tests» — последнее даёт тройной счёт, потому что XCTest печатает итог и по классу, и по набору, и по прогону. Я на этом сначала и ошибся, получив «1449».

350 тестов, 72% набора, не выполнялись никогда. Не падали — не выполнялись.

Итог сейчас: 483 теста, 2 пропуска, 122 падения, сигнала нет, фатальных нет.

Что это меняет в задаче

Разбирать надо не десять падений, а 122 — и это уже осмысленная работа, потому что число наконец полное. Прежние «10 падений» были не оценкой, а тем, сколько успело напечататься до смерти процесса.

[gHashTag]

Разбор 122 падений по составу, прежде чем чинить.

32  LogsTabViewTests
19  ModelConfigurationStoreCrossProviderTests
11  StreamingContextWatchdogIntegrationTests
11  LocalAuthProviderTests
 9  ModelHealthServiceTests
 5  ProviderCircuitBreakerTests
 5  ChatFailureTests
 4  ModelCostServiceTests
 3+ WarmupVolatilityTracker, PredictiveWarmupScheduler, MemoryStoreFTS, TriOSEncryption

Две разные природы, и их нельзя чинить одинаково

Средовые. ModelConfigurationStoreCrossProviderTests жалуется zai has no key configured и ModelHealth.unknown(error: "not stubbed"). Это не дефект продукта: тест читает настоящее наличие ключей и незаданную заглушку. Девятнадцать штук, и их надо не «чинить», а поместить в среду, где ответ определён, — как это уже сделано для keychain через TRIOS_E2E_DISABLE_KEYCHAIN=1.

Разошедшиеся ожидания. LogsTabViewTests — тридцать два, и они разные: порядок сортировки перевёрнут (("dated") is not equal to ("missing") и обратное на соседних строках), уровень разбирается как info там, где ждут warn, категория как artifact там, где ждут runtime. Это файл, который никогда не компилировался, то есть его ожидания ни разу не встречались с настоящим поведением. Каждое требует отдельного решения: тест был прав и код уплыл, или тест был неверен с самого начала.

Второй род нельзя разбирать оптом. Правка, приводящая тест к текущему поведению, — это ровно то, что запрещено: ослабление утверждения ради зелени. Здесь нужен разбор по одному, с ответом «в коде» или «в ожидании» на каждый.

Порядок

1. Сперва девятнадцать средовых: они дешевле всех и их снятие уменьшит шум на 16%.
2. Потом LogsTabViewTests по одному.
3. Остальные по убыванию.