mirror of
https://github.com/permissionlesstech/bitchat.git
synced 2026-07-27 14:25:19 +00:00
jackandClaude Opus 5
ac13a0c22f
Raising four deadlines fixed the four tests that happened to fire. The class was still there: fourteen separate waitUntil helpers, most defaulting to 1.0s, plus wait call sites with literal budgets. The fifth instance would have landed the same way, on someone else's unrelated PR. The rule, now written down in TestConstants.settleTimeout: **a wait deadline is not a latency budget.** It exists so a genuine hang eventually fails the suite, so size it for the worst-case scheduler, never for how long the operation should take. Waits return as soon as their condition holds, so a generous deadline is free in the passing case and only extends genuine failures. - Every wait helper now defaults to TestConstants.settleTimeout (30s), and the literal wait call sites below the floor were converted too — sixteen sites across ten files. - TestTimingHygieneTests enforces it by scanning the test sources: wait defaults and wait call sites must be at least minimumSettleTimeout, and no test may assert an upper bound on elapsed wall-clock time (the assertion that started this, which cannot separate correct behaviour from a slow machine). - Both rules waive per line with "test-timing-ok: <reason>", accepted on the line or in the comment block above it so the reason has room to be a sentence. One legitimate use so far: a NEGATIVE wait in NoiseCoverageTests asserting a promotion has *not* completed within 50ms, where a long deadline would only make the suite slow while still passing. Injected production timeouts are deliberately not matched — the Noise handshake timeouts are the behaviour under test, and short values are correct there. Verified the guard actually fails: a canary file with both banned shapes was flagged with file and line, and the suite went green again once it was removed. Full suite passes with all 18 cores saturated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
56 lines
2.3 KiB
Swift
56 lines
2.3 KiB
Swift
//
|
|
// TestConstants.swift
|
|
// bitchatTests
|
|
//
|
|
// This is free and unencumbered software released into the public domain.
|
|
// For more information, see <https://unlicense.org>
|
|
//
|
|
|
|
import Foundation
|
|
@testable import bitchat
|
|
|
|
struct TestConstants {
|
|
static let defaultTimeout: TimeInterval = 5.0
|
|
static let shortTimeout: TimeInterval = 1.0
|
|
/// For positive waits on work that hops through `Task.detached` or
|
|
/// background queues: those contend with every parallel test worker for
|
|
/// the global executor, so a loaded CI runner can exceed
|
|
/// `defaultTimeout`. `waitUntil` returns as soon as the condition holds,
|
|
/// so passing runs never pay the longer timeout.
|
|
static let longTimeout: TimeInterval = 10.0
|
|
|
|
/// **Default deadline for any "wait until this async thing settles" helper.**
|
|
///
|
|
/// Four separate tests flaked on CI during July 2026 with the same root
|
|
/// cause, and it is worth stating the rule rather than re-learning it a
|
|
/// fifth time: *a wait deadline is not a latency budget.* It exists so a
|
|
/// genuine hang eventually fails the suite. Size it for the worst-case
|
|
/// scheduler, never for how long the operation "should" take.
|
|
///
|
|
/// A CI runner executes many suites at once. Work behind `@MainActor`,
|
|
/// `Task.detached(priority: .utility)`, or a `DispatchQueue.asyncAfter` can
|
|
/// be starved for seconds — one observed run took 3.75 s for a 1 s
|
|
/// operation. Deadlines sized to the operation (the old 1 s defaults) turn
|
|
/// that starvation into a red build that reads like a product bug.
|
|
///
|
|
/// This costs nothing when tests pass, because every helper returns as soon
|
|
/// as its condition holds. It only extends the genuine-failure case.
|
|
///
|
|
/// `TestTimingHygieneTests` enforces that wait helpers default to at least
|
|
/// `minimumSettleTimeout`.
|
|
static let settleTimeout: TimeInterval = 30.0
|
|
|
|
/// Floor enforced by `TestTimingHygieneTests`. Anything below this is a
|
|
/// latency assumption in disguise.
|
|
static let minimumSettleTimeout: TimeInterval = 10.0
|
|
|
|
|
|
static let testNickname1 = "Alice"
|
|
static let testNickname2 = "Bob"
|
|
static let testNickname3 = "Charlie"
|
|
static let testNickname4 = "David"
|
|
|
|
static let testMessage1 = "Hello, World!"
|
|
static let testLongMessage = String(repeating: "This is a long message. ", count: 100)
|
|
}
|