mirror of
https://github.com/permissionlesstech/bitchat.git
synced 2026-07-27 09:05:19 +00:00
jackandClaude Opus 5
2d58bbcfaf
A fifth flake landed on CI while the first guard was in review — GossipSyncBoardTests timing out at 1.03s — and the guard did not catch it, because the deadline was `TestConstants.shortTimeout` rather than a literal. A literals-only scan cannot see a short value behind a symbol, which is the more common way it is written: 81 wait sites used shortTimeout (1s) or defaultTimeout (5s), every one of them below the floor. Rather than guess which of those were safe to raise, all 81 were converted and the suite timed. Runtime went 15s -> 72s, which located the genuine negative waits precisely: ten tests that assert something does *not* happen and therefore always run their deadline out. Measurement instead of a heuristic, since a mis-guess in either direction is invisible — too short reintroduces the flake, too long silently costs a minute a run. Those 28 sites now use `TestConstants.negativeWaitWindow`, a named constant whose doc explains the inverted reasoning: for a negative wait, starvation can only make the assertion *more* likely to hold, so short is correct, and the name states the polarity instead of leaving a bare literal that reads like the mistake. Suite is back to 15.3s. The guard now also rejects `timeout: TestConstants.shortTimeout` and `defaultTimeout`, while accepting `negativeWaitWindow` by name. Re-verified with a canary carrying every banned shape — literal default, both named constants, and an elapsed-time upper bound. All four were flagged with file and line; the suite went green again on removal. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
71 lines
3.2 KiB
Swift
71 lines
3.2 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
|
|
|
|
/// For waits whose **expected outcome is `false`** — "prove this does not
|
|
/// happen".
|
|
///
|
|
/// The floor above is wrong for these, and inverted: a negative wait always
|
|
/// runs its deadline out, so `settleTimeout` would spend 30 s per case
|
|
/// proving nothing extra. Starvation cannot cause a false failure here
|
|
/// either — a starved runner only makes the thing *less* likely to happen,
|
|
/// so the assertion still holds. Short is correct, and naming it says the
|
|
/// polarity out loud instead of leaving a bare literal that reads like the
|
|
/// mistake this file exists to prevent.
|
|
///
|
|
/// `TestTimingHygieneTests` accepts this by name. Using it for a wait you
|
|
/// expect to succeed reintroduces exactly the flake class it sits next to.
|
|
static let negativeWaitWindow: TimeInterval = 1.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)
|
|
}
|