15 · 테스트와 디버깅

import XCTest

// UI test는 프로세스 기동·렌더 대기 때문에 유닛 테스트의 수백 배 느리고
// 외부 요인에 취약하다. 많아지면 팀이 실패를 무시하기 시작한다.

final class CheckoutUITests: XCTestCase {

    // ✅ 이 정도만 UI test로 — 깨지면 매출이 멈추는 경로
    func test_결제_해피패스() {
        let app = XCUIApplication()
        app.launchArguments = ["-UITest", "-MockNetwork"]   // ✅ 결정적으로 만든다
        app.launch()

        app.buttons["상품 담기"].tap()
        app.buttons["장바구니"].tap()
        app.buttons["결제하기"].tap()

        // ✅ sleep이 아니라 조건을 기다린다
        let done = app.staticTexts["결제 완료"]
        XCTAssertTrue(done.waitForExistence(timeout: 15))
    }

    // ❌ 이런 건 UI test로 하지 않는다 — 유닛으로 내린다
    // func test_할인율_경계값() { ... }
    // func test_이메일_형식_검증() { ... }
    // func test_빈_장바구니_에러메시지() { ... }
}

// ✅ 같은 검증을 유닛으로 — 밀리초 단위로 끝나고 케이스를 많이 넣을 수 있다
import Testing

@Test(arguments: [
    (9_999, 0.0), (10_000, 0.1), (49_999, 0.1), (50_000, 0.2)
])
func 할인율_경계값(amount: Int, expected: Double) {
    #expect(Pricing.discountRate(for: amount) == expected)
}

// ❌ 절대 하지 말 것
//   · 실제 프로덕션 서버를 때리는 테스트 (다른 팀 배포에 우리 CI가 깨진다)
//   · sleep으로 화면 전환 대기 (기기 성능에 따라 flaky)
//   · 테스트 간 상태 공유 (실행 순서에 의존하게 된다)

enum Pricing {
    static func discountRate(for amount: Int) -> Double { 0 }
}

import Testing
import Foundation

// Integration test의 가치는 '내가 못 바꾸는 것과의 계약'을 지키는 데 있다.
// 서버 JSON 스키마, DB 마이그레이션, 서드파티 SDK 동작이 그 대상이다.

// ✅ ① 서버 응답 계약 — 실제 응답 샘플을 픽스처로 고정한다
@Test func 주문_응답_스키마가_모델과_맞는다() throws {
    let url = Bundle.module.url(forResource: "order_response", withExtension: "json")!
    let data = try Data(contentsOf: url)

    let order = try JSONDecoder.api.decode(Order.self, from: data)

    #expect(order.id == "ord_123")
    #expect(order.items.count == 3)
    #expect(order.status == .completed)      // enum 매핑까지 확인
}

// ✅ 서버가 필드를 추가해도 안 깨지는지 (전방 호환)
@Test func 알수없는_필드가_있어도_디코딩된다() throws {
    let json = """
    {"id":"ord_1","status":"completed","items":[],"newFieldFromServer":123}
    """
    let order = try JSONDecoder.api.decode(Order.self, from: Data(json.utf8))
    #expect(order.id == "ord_1")
}

// ✅ ② DB 스키마·마이그레이션
@Test func v3에서_v4로_마이그레이션된다() throws {
    let store = try TestStore.copyFixture(version: 3)
    try store.migrate()
    #expect(try store.schemaVersion() == 4)
    #expect(try store.orderCount() > 0)      // 데이터 보존까지 확인
}

// ❌ 순수 로직에 Integration을 쓰면 느리기만 하다
// @Test func 할인_계산() { DB를 띄우고 서버를 붙이고... }  ← 유닛으로 충분하다

struct Order: Decodable {
    let id: String
    let items: [Item]
    let status: Status
    enum Status: String, Decodable { case pending, completed }
    struct Item: Decodable {}
}
extension JSONDecoder { static let api = JSONDecoder() }
enum TestStore {
    static func copyFixture(version: Int) throws -> Store { Store() }
}
struct Store {
    func migrate() throws {}
    func schemaVersion() throws -> Int { 4 }
    func orderCount() throws -> Int { 1 }
}

import XCTest

// 이 둘이 flaky 테스트의 압도적 1·2위다.

// ❌ ① 실제 서버를 때린다
final class BadNetworkTests: XCTestCase {
    func test_피드_조회() async throws {
        let data = try await URLSession.shared.data(
            from: URL(string: "https://api.production.com/feed")!).0
        XCTAssertFalse(data.isEmpty)
        // 💥 서버 배포·네트워크·데이터 변경에 우리 CI가 흔들린다
        // 💥 병렬 실행 시 서로 간섭한다
        // 💥 오프라인에서 못 돌린다
    }
}

// ✅ URLProtocol로 네트워크를 가로챈다 — 실제 통신 없이 결정적으로
final class MockURLProtocol: URLProtocol {
    nonisolated(unsafe) static var handler: ((URLRequest) throws -> (HTTPURLResponse, Data))?

    override class func canInit(with request: URLRequest) -> Bool { true }
    override class func canonicalRequest(for request: URLRequest) -> URLRequest { request }

    override func startLoading() {
        guard let handler = Self.handler else { return }
        do {
            let (response, data) = try handler(request)
            client?.urlProtocol(self, didReceive: response, cacheStoragePolicy: .notAllowed)
            client?.urlProtocol(self, didLoad: data)
            client?.urlProtocolDidFinishLoading(self)
        } catch {
            client?.urlProtocol(self, didFailWithError: error)
        }
    }
    override func stopLoading() {}
}

func makeMockSession() -> URLSession {
    let config = URLSessionConfiguration.ephemeral
    config.protocolClasses = [MockURLProtocol.self]
    return URLSession(configuration: config)
}

// ❌ ② sleep으로 대기
func badWait(_ app: XCUIApplication) {
    app.buttons["결제"].tap()
    sleep(3)                                   // 💥 느린 기기에선 부족, 빠른 기기에선 낭비
    XCTAssertTrue(app.staticTexts["완료"].exists)
}

// ✅ 조건을 기다린다
func goodWait(_ app: XCUIApplication) {
    app.buttons["결제"].tap()
    XCTAssertTrue(app.staticTexts["완료"].waitForExistence(timeout: 10))
}

// ✅ 비동기 코드는 신호 기반으로
func awaitCondition() async throws {
    let value = try await loadValue()          // await 자체가 동기화 지점
    XCTAssertNotNil(value)
}
func loadValue() async throws -> String? { nil }

git bisect start
git bisect bad HEAD
git bisect good v1.4.0
# 각 후보 커밋에서 이 테스트만 돌려 자동으로 good/bad 판정
git bisect run xcodebuild test \
  -scheme App -destination 'platform=iOS Simulator,name=iPhone 16' \
  -only-testing:AppTests/CrashReproTests/test_repro
git bisect reset

import Testing
import Foundation

// 순서가 중요하다: 재현 → 테스트로 고정 → 수정 → 테스트 통과.
// 이 순서를 지키면 "고쳤다"를 증명할 수 있고, 그 테스트가 회귀 방어선이 된다.

// 버그 리포트: "자정 직전에 만든 주문이 다음 날 그룹에 들어간다"

// ① 먼저 실패하는 테스트를 쓴다
@Test func 자정_직전_주문은_같은_날짜로_묶인다() {
    let clock = FixedClock(now: iso("2026-07-27T23:59:00+09:00"))
    let grouper = OrderGrouper(clock: clock, timeZone: TimeZone(identifier: "Asia/Seoul")!)

    let order = Order(createdAt: iso("2026-07-27T23:59:00+09:00"))
    let groups = grouper.group([order])

    #expect(groups.keys.first == "2026-07-27")   // 지금은 "2026-07-28"이 나온다
}

// ② 이 테스트가 통과하도록 고친다 (원인: UTC 기준으로 날짜를 잘랐다)
// ③ 통과 후에는 그대로 두어 회귀를 막는다

// ✅ 경계값을 함께 넣으면 같은 종류의 버그를 미리 막는다
@Test(arguments: [
    ("2026-07-27T00:00:00+09:00", "2026-07-27"),
    ("2026-07-27T23:59:59+09:00", "2026-07-27"),
    ("2026-07-28T00:00:00+09:00", "2026-07-28"),
])
func 날짜_경계(_ input: String, _ expected: String) {
    let grouper = OrderGrouper(clock: FixedClock(now: iso(input)),
                               timeZone: TimeZone(identifier: "Asia/Seoul")!)
    #expect(grouper.group([Order(createdAt: iso(input))]).keys.first == expected)
}

struct FixedClock { let now: Date }
struct Order { let createdAt: Date }
struct OrderGrouper {
    let clock: FixedClock
    let timeZone: TimeZone
    func group(_ orders: [Order]) -> [String: [Order]] { [:] }
}
func iso(_ s: String) -> Date {
    ISO8601DateFormatter().date(from: s) ?? Date()
}

import Foundation
import UIKit

// "내 기기에서만 재현"은 환경 변수 중 하나가 다른 것이다.
// 추측하지 말고 목록을 만들어 팀원과 대조한다.

struct DiagnosticSnapshot: Codable, CustomStringConvertible {
    let osVersion: String
    let deviceModel: String
    let locale: String
    let timeZone: String
    let calendar: String
    let preferredLanguages: [String]
    let isLowPowerMode: Bool
    let thermalState: String
    let freeDiskGB: Double
    let accessibilityTextSize: String
    let appVersion: String
    let buildNumber: String

    @MainActor init() {
        let info = ProcessInfo.processInfo
        osVersion = info.operatingSystemVersionString
        deviceModel = { var s = utsname(); uname(&s); return withUnsafeBytes(of: &s.machine) {
            String(cString: $0.baseAddress!.assumingMemoryBound(to: CChar.self)) } }()
        // 예: "iPhone17,1" — UIDevice.current.model은 "iPhone"만 줘서 diff에 못 쓴다
        locale = Locale.current.identifier
        timeZone = TimeZone.current.identifier
        calendar = Calendar.current.identifier.debugDescription
        preferredLanguages = Locale.preferredLanguages
        isLowPowerMode = info.isLowPowerModeEnabled
        thermalState = "\(info.thermalState)"
        accessibilityTextSize = UIApplication.shared
            .preferredContentSizeCategory.rawValue

        let attrs = try? FileManager.default.attributesOfFileSystem(
            forPath: NSHomeDirectory())
        freeDiskGB = Double((attrs?[.systemFreeSize] as? Int64) ?? 0) / 1e9

        appVersion = Bundle.main
            .infoDictionary?["CFBundleShortVersionString"] as? String ?? "-"
        buildNumber = Bundle.main.infoDictionary?["CFBundleVersion"] as? String ?? "-"
    }

    var description: String {
        (try? String(data: JSONEncoder().encode(self), encoding: .utf8)) ?? ""
    }
}

// ✅ 버그 리포트 화면에서 자동 첨부한다 — 사용자가 손으로 적게 하지 않는다
@MainActor
func attachDiagnostics(to report: inout BugReport) {
    report.environment = DiagnosticSnapshot().description
}

// 자주 범인이 되는 항목
//   타임존·달력 (음력, 일본 연호)
//   지역 설정 (숫자 구분자 "1.234,56" vs "1,234.56")
//   접근성 텍스트 크기 (레이아웃 깨짐)
//   저장공간 부족 (캐시 삭제, 쓰기 실패)
//   저전력 모드 (백그라운드 작업 중단)

struct BugReport { var environment: String = "" }

import Foundation

// 재현하지 못한 채 "아마 이거겠지" 하고 고치면
//   ① 진짜 원인이 아닐 확률이 높고
//   ② 고쳐졌는지 검증할 방법이 없고
//   ③ 엉뚱한 코드에 방어 코드만 쌓인다

// ❌ 전형적인 패턴 — 원인 모르는 크래시에 nil 체크를 덧대기
func brokenFix(_ items: [Item]?, _ index: Int) -> Item? {
    guard let items, index >= 0, index < items.count else { return nil }
    return items[index]
    // 크래시는 안 나지만, '왜 index가 범위를 벗어났는지'는 그대로 남아 있다.
    // 화면에 빈 값이 나오는 새로운 버그로 바뀌었을 뿐이다.
}

// ✅ 재현이 안 되면 '재현 가능하게 만드는 것'이 먼저다
//    ① 결정성 확보 — 시드·시간·네트워크를 고정
struct SeededGenerator: RandomNumberGenerator {
    private var state: UInt64
    init(seed: UInt64) { state = seed }
    mutating func next() -> UInt64 {
        state = state &* 6364136223846793005 &+ 1442695040888963407
        return state
    }
}

func reproducibleShuffle(_ items: [Item], seed: UInt64) -> [Item] {
    var rng = SeededGenerator(seed: seed)
    return items.shuffled(using: &rng)        // 항상 같은 순서
}

//    ② 로그·상태를 크래시 지점에 남긴다
func instrumented(_ items: [Item], _ index: Int) -> Item {
    // fatalError는 릴리스(-O)에서도 메시지를 남긴다 — precondition은 메시지가 사라진다
    if index >= items.count {
        fatalError("index=\(index) count=\(items.count) — 호출자를 추적할 것")
    }
    return items[index]
    // 크래시 리포트에 상태가 남아 다음 발생 때 원인이 보인다
}

//    ③ 그래도 안 되면 원격 로깅으로 실사용자 데이터를 모은다
func recordContext(_ index: Int, _ count: Int) {
    // Analytics.record("index_mismatch", ["index": index, "count": count])
}

// ✅ 재현에 성공하면 그 즉시 테스트로 고정한다(앞 항목)

struct Item {}

Thread 0 Crashed:
0   libswiftCore.dylib   0x1a2...  _assertionFailure + 320
1   MyApp                0x104a9c1f0   0x104a80000 + 115184   # <- 오프셋뿐

# dSYM으로 오프셋 -> 함수/파일/라인
atos -arch arm64 \
  -o MyApp.app.dSYM/Contents/Resources/DWARF/MyApp \
  -l 0x104a80000  0x104a9c1f0
# => Cart.total() (in MyApp) (Cart.swift:42)

# dSYM이 없으면 사후 크래시 로그는 오프셋 숫자일 뿐이다.
# 코드를 아무리 들여다봐도 어디서 죽었는지 알 수 없다.

# ✅ ① 릴리스 구성에서 생성 강제
xcodebuild archive -scheme MyApp -configuration Release \
  -archivePath build/MyApp.xcarchive \
  DEBUG_INFORMATION_FORMAT=dwarf-with-dsym

# ✅ ② 버전별로 영구 보관 (재빌드하면 UUID가 바뀌어 못 쓴다)
VERSION=$(/usr/libexec/PlistBuddy -c "Print :CFBundleShortVersionString" \
          build/MyApp.xcarchive/Products/Applications/MyApp.app/Info.plist)
BUILD=$(/usr/libexec/PlistBuddy -c "Print :CFBundleVersion" \
        build/MyApp.xcarchive/Products/Applications/MyApp.app/Info.plist)
mkdir -p ~/dSYMs/"$VERSION-$BUILD"
cp -R build/MyApp.xcarchive/dSYMs/* ~/dSYMs/"$VERSION-$BUILD"/

# ✅ ③ 크래시 리포터에 업로드 (CI 자동화)
find build/MyApp.xcarchive/dSYMs -name "*.dSYM" -print0 \
  | xargs -0 sentry-cli debug-files upload --org my-org --project my-app

# ✅ ④ 의존 프레임워크 dSYM이 빠지지 않았는지 확인
ls build/MyApp.xcarchive/dSYMs/
#   MyApp.app.dSYM
#   Core.framework.dSYM
#   Analytics.framework.dSYM     ← 서드파티 것도 있어야 그 안이 풀린다

# ✅ ⑤ 업로드 누락을 CI에서 잡는다
EXPECTED=$(otool -L build/.../MyApp | grep -c '@rpath')
FOUND=$(ls build/MyApp.xcarchive/dSYMs | wc -l)
[ "$FOUND" -ge "$EXPECTED" ] || { echo "❌ dSYM 누락"; exit 1; }

# ⚠️ App Store Connect에서 "빌드에 dSYM 누락" 경고가 뜨면
#    Organizer → Archives → Download Debug Symbols는 bitcode 재컴파일 빌드에만 있던 경로이고, Xcode 14부터 App Store가 bitcode를 받지 않으므로 지금 올리는 빌드에는 해당되지 않는다 — 아카이브 시점에 보관하지 못했으면 그 빌드의 로그는 복구할 수 없다(Bitcode 사용 시)

/*  프레임을 읽을 때 시스템 프레임을 건너뛰되, 그 '이름'은 보고 지나간다.
    무엇이 죽었는지 성격을 알려 주기 때문이다.

    ── over-release / use-after-free
    0  libobjc.A.dylib   objc_release + 16
    1  libobjc.A.dylib   objc_object::sidetable_release
    2  MyApp             ImageCache.evict()
    → 이미 해제된 객체를 다시 release. Zombies·ASan으로 재현한다.

    ── 레이아웃 중 접근
    0  UIKitCore   -[UIView layoutSubviews]
    1  UIKitCore   -[UIView _layoutSublayersOfLayer:]
    2  MyApp       FeedCell.layoutSubviews()
    → 레이아웃 사이클 중 뷰 계층을 바꿨거나 순환 제약.

    ── 메인 스레드 아님
    0  UIKitCore   _UIAssertionFailureHandler
    1  UIKitCore   -[UIView setNeedsLayout]
    → 백그라운드에서 UIKit 호출. Main Thread Checker로 잡는다.

    ── Swift 런타임 트랩
    0  libswiftCore.dylib  _swift_runtime_on_report
    1  libswiftCore.dylib  _assertionFailure
    2  MyApp               OrderService.submit()
    → 강제 언래핑 nil, 배열 범위 초과, fatalError/precondition.
      (swift_unexpectedError가 보이면 try!가 에러를 던진 것,
       swift_dynamicCastFailure면 강제 캐스팅 실패다.)

    ── 워치독
    Exception Type: EXC_CRASH (SIGKILL)
    Termination Reason: 0x8badf00d
    → 크래시가 아니라 메인 스레드 정지. 스택은 '멈춰 있던 지점'이다.

    ── 스택 오버플로
    0  MyApp  parseNode(_:)
    1  MyApp  parseNode(_:)
    ... 같은 프레임이 수천 번 반복
    → 무한 재귀. 종료 조건을 확인한다.                                      */

// ✅ 크래시 스레드를 먼저 찾는다 — 항상 Thread 0이 아니다
//    리포트에서 "Crashed:" 또는 "Thread N Crashed:" 표시를 찾는다

// ✅ Exception Type도 함께 읽는다
//    EXC_BAD_ACCESS (SIGSEGV)  → 잘못된 메모리 접근
//    EXC_BREAKPOINT (SIGTRAP)  → Swift 런타임 트랩 (강제 언래핑 등)
//    EXC_CRASH (SIGABRT)       → 처리되지 않은 예외, assertion
//    EXC_RESOURCE              → 메모리·CPU 한도 초과

/*  ❌ 이런 리포트를 놓고 코드를 추측하는 건 시간 낭비다

    Thread 0 Crashed:
    0   MyApp    0x0000000104b9c1f4 0x104b78000 + 148468
    1   MyApp    0x0000000104ba2318 0x104b78000 + 172312
    2   UIKitCore 0x00000001a2c4d8f0 0x1a2b00000 + 1366256

    → 어느 함수인지, 어느 줄인지 전혀 알 수 없다.                          */

// ✅ 먼저 심볼리케이션을 해결한다

// ① UUID 일치 확인
//    dwarfdump --uuid MyApp.app.dSYM
//    → 리포트의 Binary Images 섹션 UUID와 대조

// ② 수동 심볼리케이션 — 로드 주소와 크래시 주소를 넣는다
//    atos -o MyApp.app.dSYM/Contents/Resources/DWARF/MyApp \
//         -arch arm64 -l 0x104b78000 0x104b9c1f4
//    → OrderViewModel.submit() (OrderViewModel.swift:142)

// ③ 리포트 전체를 한 번에
//    export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
//    "$DEVELOPER_DIR/usr/bin/symbolicatecrash" crash.ips MyApp.app.dSYM

// ④ Xcode Organizer에 넣으면 자동으로 붙는다
//    Window → Organizer → Crashes (dSYM이 업로드돼 있어야 한다)

// ⚠️ 심볼리케이션이 끝까지 안 되면 그 리포트는 사실상 못 쓴다.
//    "대략 이 근처일 것"으로 고치면 엉뚱한 코드를 건드리게 된다.

// ✅ 애초에 심볼리케이션 없이도 원인이 보이게 만드는 방법
//    · 크래시 직전 상태를 breadcrumb으로 남긴다
//    · precondition 메시지에 값을 담는다
//        if index >= count { fatalError("index=\(index) count=\(count)") }
//      → 리포트의 Application Specific Information에 그대로 찍힌다
//      (precondition·preconditionFailure의 메시지는 릴리스(-O)에서 사라진다)
//    · 화면 전환·주요 액션을 커스텀 키로 기록한다

struct SearchModel {
  let clock: any Clock<Duration>
  var onResults: ([String]) -> Void = { _ in }

  func search(_ q: String) async throws {
    try await clock.sleep(for: .milliseconds(300))   // debounce
    onResults(try await api.query(q))
  }
}

@Test func debounceFiresAfter300ms() async throws {
  let clock = TestClock()
  let model = SearchModel(clock: clock)
  async let task: Void = model.search("swift")
  await clock.advance(by: .milliseconds(300))   // 실제 대기 0초
  try await task                                // 여기서 결정적으로 완료
}

import Foundation

// Date()·Task.sleep을 코드에 직접 박으면 그 지점부터 테스트가 불가능해진다.

// ❌ 시간이 하드코딩됐다
struct BadSessionTimer {
    func waitForTimeout() async throws {
        try await Task.sleep(for: .seconds(1800))   // 테스트에서 30분을 기다릴 수 없다
    }
    func isExpired(_ token: Token) -> Bool {
        token.expiresAt < Date()                    // 현재 시각을 통제할 수 없다
    }
}

// ✅ Clock을 주입받는다
struct SessionTimer<C: Clock> where C.Duration == Duration {
    let clock: C
    let timeout: Duration

    func waitForTimeout() async throws {
        try await clock.sleep(for: timeout)
    }
}

// ✅ 현재 시각도 주입한다 — 가장 단순한 형태는 클로저다
struct TokenValidator {
    var now: () -> Date = { Date() }

    func isExpired(_ token: Token) -> Bool {
        token.expiresAt < now()
    }
}

// 프로덕션
let production = TokenValidator()

// 테스트 — 시각을 원하는 대로 고정한다
func test_만료_판정() {
    let fixed = Date(timeIntervalSince1970: 1_800_000_000)
    let validator = TokenValidator(now: { fixed })

    let expired = Token(expiresAt: fixed.addingTimeInterval(-1))
    let valid = Token(expiresAt: fixed.addingTimeInterval(1))

    assert(validator.isExpired(expired))
    assert(!validator.isExpired(valid))
}

// ✅ 프로토콜로 추상화하면 더 넓게 쓸 수 있다
protocol DateProvider: Sendable {
    var now: Date { get }
}
struct SystemDateProvider: DateProvider {
    var now: Date { Date() }
}
struct FixedDateProvider: DateProvider {
    let now: Date
}

struct Token { let expiresAt: Date }

import Testing
import XCTest
import Foundation

// "그 안엔 끝나겠지"는 느린 CI에서 반드시 깨진다.

// ❌ 시간에 기대는 대기
func badWait() async throws {
    startBackgroundWork()
    try await Task.sleep(for: .seconds(1))     // 💥 느리면 실패, 빠르면 낭비
    assert(isDone)
}

// ✅ ① async/await — await 자체가 동기화 지점이다
@Test func 작업이_완료된다() async throws {
    let result = try await performWork()       // 끝날 때까지 정확히 기다린다
    #expect(result == .success)
}

// ✅ ② 콜백 API는 continuation으로 감싼다
func performLegacy() async throws -> Int {
    try await withCheckedThrowingContinuation { cont in
        legacyAPI { result in cont.resume(with: result) }
    }
}

// ✅ ③ XCTest에서는 expectation
final class LegacyTests: XCTestCase {
    func test_콜백_완료() {
        let expectation = expectation(description: "작업 완료")
        var received: Int?

        legacyAPI { result in
            received = try? result.get()
            expectation.fulfill()              // ✅ 신호
        }

        wait(for: [expectation], timeout: 5)   // 타임아웃은 '실패 판정용' 상한일 뿐
        XCTAssertNotNil(received)
    }
}

// ✅ ④ 상태 변화를 기다려야 하면 AsyncStream으로 신호를 만든다
func waitForState(_ target: State, in stream: AsyncStream<State>) async {
    for await state in stream where state == target { return }
}

// ⚠️ timeout 값은 '정상 동작 시간'이 아니라 '이보다 오래 걸리면 버그'인 상한이다.
//    5초 걸리는 작업에 timeout 5초를 주면 그 자체가 flaky의 원인이 된다.

enum State { case idle, done }
enum Result2 { case success }
func startBackgroundWork() {}
var isDone = false
func performWork() async throws -> Result2 { .success }
func legacyAPI(_ done: @escaping (Result<Int, Error>) -> Void) {}

import Foundation
import Testing

// 이 셋이 테스트에 남아 있으면 그 테스트는 언젠가 반드시 흔들린다.

// ❌ ① 실제 Date()
struct BadReport {
    func title() -> String {
        "오늘의 리포트 — \(Date().formatted(date: .numeric, time: .omitted))"
        // 자정에 실행되면 날짜가 바뀌어 스냅샷 테스트가 깨진다
    }
}
// ✅ 주입
struct Report {
    let now: Date
    func title() -> String {
        "오늘의 리포트 — \(now.formatted(date: .numeric, time: .omitted))"
    }
}

// ❌ ② 시드 없는 난수
func badShuffle(_ items: [Int]) -> [Int] {
    items.shuffled()                    // 매 실행마다 다른 결과
}
// ✅ 생성기를 주입
struct SeededGenerator: RandomNumberGenerator {
    private var state: UInt64
    init(seed: UInt64) { state = seed }
    mutating func next() -> UInt64 {
        state = state &* 6364136223846793005 &+ 1442695040888963407
        return state
    }
}
func shuffle(_ items: [Int], using rng: inout some RandomNumberGenerator) -> [Int] {
    items.shuffled(using: &rng)
}

// ❌ ③ 실제 네트워크 — 앞 항목의 MockURLProtocol로 대체한다

// ✅ 남아 있는지 CI에서 검사한다 (SwiftLint 커스텀 룰)
/*
  custom_rules:
    no_date_in_tests:
      included: '.*Tests?\.swift'
      regex: 'Date\(\)'
      message: "테스트에서 Date()를 직접 쓰지 마세요. 시각을 주입하세요."
      severity: error

    no_real_network_in_tests:
      included: '.*Tests?\.swift'
      regex: 'URLSession\.shared'
      message: "테스트에서 URLSession.shared를 쓰지 마세요. Mock을 주입하세요."
      severity: error
*/

// ✅ flaky를 발견하면 반복 실행으로 확인한다
//    xcodebuild test -test-iterations 50 -run-tests-until-failure

# 1) 코드 위치 breakpoint
(lldb) breakpoint set --file CartVC.swift --line 42

# 2) symbolic breakpoint (소스 없어도, 모든 인스턴스에)
(lldb) breakpoint set --name "-[UIViewController viewDidLoad]"
(lldb) breakpoint set --name "MyApp.CartViewModel.checkout()"

# 3) watchpoint: 이 값이 '언제·어디서' 바뀌는지 잡는다
(lldb) watchpoint set variable self.balance
(lldb) watchpoint set expression -- &globalCounter

# 로그를 흩뿌리기 전에 watchpoint를 먼저 쓴다. 한 번에 변경 지점을 잡는다.

# ✅ ① 프로퍼티에 걸기 — 객체를 알고 있을 때
(lldb) po self
(lldb) watchpoint set variable self.items
#   Watchpoint created: Watchpoint 1: addr = 0x600001f04a18 size = 8
(lldb) continue
#   값이 바뀌는 순간 멈춘다
(lldb) bt
#   → 누가 바꿨는지 콜스택이 그대로 나온다

# ✅ ② 주소로 걸기 — 전역이나 특정 메모리 위치
(lldb) expression -- &globalCounter
(lldb) watchpoint set expression -- 0x100a4b2c0

# ✅ ③ 읽기까지 감시
(lldb) watchpoint set variable -w read_write self.state

# ✅ ④ 조건을 붙여 좁힌다 (뜨거운 값에 필수)
(lldb) watchpoint modify -c 'self.items.count > 100' 1

# ✅ ⑤ 멈출 때 자동으로 정보를 찍고 계속 진행
(lldb) watchpoint command add 1
> bt 5
> po self.items.count
> continue
> DONE

# ✅ 관리
(lldb) watchpoint list
(lldb) watchpoint disable 1
(lldb) watchpoint delete 1

# ⚠️ 하드웨어 디버그 레지스터로 구현되어 동시 개수(보통 4개)와
#    감시 바이트 크기에 물리적 상한이 있다. 초과하면 설정이 실패한다.

# ⚠️ Swift에서 값 타입 프로퍼티는 주소가 자주 바뀌어 watchpoint가 풀릴 수 있다.
#    클래스 프로퍼티나 전역에서 가장 잘 동작한다.

# 내 코드에 로그를 넣지 않고도 프레임워크 동작을 관찰할 수 있다.

# ✅ ① 메서드 이름으로 걸기
(lldb) breakpoint set -n "-[UIViewController viewDidAppear:]"
(lldb) breakpoint set -n "-[UIView setNeedsLayout]"

# ✅ ② 정규식으로 여러 개를 한 번에
(lldb) breakpoint set -r 'UIView.*layoutSubviews'

# ✅ ③ Swift 심볼
(lldb) breakpoint set -n 'MyApp.OrderViewModel.submit() -> ()'

# ✅ ④ Xcode UI에서 (Breakpoint Navigator → + → Symbolic Breakpoint)
#    Symbol: -[UIViewController viewWillAppear:]
#    Condition: (BOOL)[[$arg1 description] containsString:@"FeedVC"]
#    Action: po $arg1
#    Options: ✓ Automatically continue after evaluating

# ✅ ⑤ 자주 쓰는 진단용 브레이크포인트들
(lldb) breakpoint set -n malloc_error_break        # 힙 손상
(lldb) breakpoint set -n objc_exception_throw      # ObjC 예외 발생 지점
(lldb) breakpoint set -n UIViewAlertForUnsatisfiableConstraints   # 제약 충돌

# throw된 Swift 에러에서 멈춘다 (Xcode의 'Swift Error' 브레이크포인트와 같은 심볼)
#   ⚠️ 강제 언래핑 nil·배열 범위 초과 같은 런타임 트랩은 여기 안 걸린다 —
#      그건 EXC_BREAKPOINT 트랩이라 디버거가 자동으로 멈춘다
(lldb) breakpoint set -n swift_willThrow

# ⚠️ 심볼릭 브레이크포인트는 이름이 맞는 '모든 것'에 걸린다.
#    UIKit이 내부적으로 수백 번 부르는 메서드면 앱이 사실상 멈춘다.
#    → 반드시 조건으로 좁힌다.

# ✅ 조건 예시 — 특정 클래스에서만
(lldb) breakpoint modify -c '[[$arg1 class] isEqual:[FeedViewController class]]' 1

# watchpoint는 감시 대상에 '접근할 때마다' 실행을 멈춘다.
# 프레임마다 바뀌는 값에 걸면 디버깅이 아니라 마비다.

# ❌ 이런 곳에 걸면 안 된다
#   · 애니메이션 진행률 (프레임마다 60~120회)
#   · 스크롤 오프셋
#   · 루프 카운터
#   · 매 프레임 갱신되는 렌더 상태

# ✅ ① 조건으로 좁힌다 — 특정 값이 될 때만 멈춘다
(lldb) watchpoint set variable self.progress
(lldb) watchpoint modify -c 'self.progress > 0.99' 1

# ✅ ② 멈추지 말고 로그만 남긴다
(lldb) watchpoint command add 1
> po self.progress
> bt 3
> continue
> DONE
#   → 실행은 계속되고 변경 이력만 콘솔에 쌓인다

# ✅ ③ 무시 횟수를 준다 — N번째 변경부터 멈춘다
(lldb) watchpoint ignore -i 1000 1

# ✅ ④ 필요한 구간에서만 켠다
(lldb) watchpoint disable 1
#   ... 원하는 화면까지 진행 ...
(lldb) watchpoint enable 1

# ✅ ⑤ 코드로 켜고 끄는 방법 — 특정 시점에만 감시
#    문제 구간 직전에 브레이크포인트를 걸고, 거기서 watchpoint를 설정한다

# ⚠️ 대안: 뜨거운 값의 변경 이력이 필요하면 watchpoint보다
#    didSet에 조건부 로깅을 넣는 편이 실용적이다
#      var progress: Double {
#          didSet {
#              #if DEBUG
#              if progress > 0.99 { print("progress=\(progress)"); }
#              #endif
#          }
#      }

import Foundation

/*  증상 → 도구 매핑

    느리다 · 버벅인다
      → Time Profiler       "CPU 시간이 어디서 쓰이나"
      → Animation Hitches   "어느 프레임이 예산을 넘겼나"

    메모리가 계속 느는데 안 죽는다
      → Allocations (Generation 분석)  "무엇이 안 놓이나"
      → Memory Graph Debugger          "누가 붙들고 있나"

    확실히 새는 것 같다 (도달 불가 메모리)
      → Leaks

    배터리·발열
      → Energy Log · CPU Counters

    디스크·네트워크가 느리다
      → File Activity · Network

    앱 시작이 느리다
      → App Launch                                                          */

// ✅ 도구를 켜기 전에 '재현 시나리오'를 먼저 정한다
//    "피드를 20번 스크롤한 뒤 상세로 들어갔다 나오기" 처럼
//    같은 동작을 반복 가능하게 만들어야 개선 전후를 비교할 수 있다

// ✅ 코드로 상시 감시선을 두면 회귀를 빨리 잡는다
import XCTest

final class PerformanceTests: XCTestCase {
    func test_피드_파싱_성능() {
        let data = loadFixture()
        measure(metrics: [XCTClockMetric(), XCTMemoryMetric()]) {
            _ = try? JSONDecoder().decode([Item].self, from: data)
        }
    }

    func test_화면_해제됨() {
        weak var weakVC: FeedViewController?
        autoreleasepool {
            let vc = FeedViewController()
            vc.loadViewIfNeeded()
            weakVC = vc
        }
        XCTAssertNil(weakVC, "abandoned memory — 루트 어딘가가 붙들고 있다")
    }

    private func loadFixture() -> Data { Data() }
}

struct Item: Decodable {}
final class FeedViewController: UIViewController {}
import UIKit

import Foundation

// Time Profiler는 일정 간격으로 콜스택을 표본 추출한다.
// 절대 밀리초는 표본 오차가 크므로, '가장 큰 덩어리'를 찾는 데 쓴다.

/*  읽는 순서
      ① 문제 구간만 선택한다 (전체 녹화에서 버벅인 구간을 드래그)
      ② "Separate by Thread" 켜고 메인 스레드를 본다
      ③ "Hide System Libraries" 켜서 내 코드만 남긴다
      ④ Invert Call Tree로 '가장 아래에서 시간을 쓰는 함수'를 본다
      ⑤ 가장 큰 항목부터 하나씩 개선한다

    ⚠️ mach_msg_trap이 많다고 문제가 아니다 — 런루프가 자고 있는 상태다.
       Record Waiting Threads를 꺼 두면 대기 표본이 제외되어 실제 작업만 남는다.        */

// ✅ 개선 전후를 같은 시나리오로 비교한다
func measureScenario(_ label: String, _ body: () -> Void) {
    let clock = ContinuousClock()
    var samples: [Duration] = []
    for _ in 0..<10 { samples.append(clock.measure(body)) }
    samples.sort()
    print("\(label): 중앙값 \((samples[4] + samples[5]) / 2) · p90 \(samples[8]) · 최악 \(samples[9])")
    // 평균이 아니라 중앙값·p90을 본다 — 이상치에 덜 흔들린다
}

// ✅ signpost로 내 코드의 구간을 Instruments 타임라인에 표시한다
import os.signpost

let perfLog = OSLog(subsystem: "com.app.perf", category: .pointsOfInterest)

func parseWithSignpost(_ data: Data) throws -> [Item] {
    let id = OSSignpostID(log: perfLog)
    os_signpost(.begin, log: perfLog, name: "parse feed", signpostID: id)
    defer { os_signpost(.end, log: perfLog, name: "parse feed", signpostID: id) }
    return try JSONDecoder().decode([Item].self, from: data)
}
// → Instruments의 os_signpost 트랙에 구간이 그대로 보인다

struct Item: Decodable {}

import Foundation

// Debug 빌드와 시뮬레이터는 실제와 다른 세계다. 두 가지가 동시에 왜곡한다.

/*  ① 최적화 차이 (-Onone vs -O)
      · ARC retain/release가 중복까지 그대로 방출된다
      · 제네릭이 특수화되지 않아 witness table 동적 디스패치를 탄다
      · 인라인이 거의 안 된다
      → 계산 중심 코드는 수십 배까지 느리게 나온다

    ② 아키텍처·하드웨어 차이 (시뮬레이터)
      · 맥의 CPU로 돈다 — 코어 성능·개수·캐시가 전혀 다르다
      · 디스크가 SSD(맥)라 I/O가 훨씬 빠르다
      · 메모리 상한이 없다시피 하다 → jetsam이 재현되지 않는다
      · GPU도 맥의 것이라 렌더 성능이 다르다                                */

// ✅ 성능 측정의 최소 조건
//    · Release 구성 (또는 최적화를 켠 커스텀 구성)
//    · 실기기
//    · 지원하는 가장 낮은 사양 기기로도 한 번
//    · 저전력 모드·발열 상태를 통제

// ✅ 코드로 실수를 막는다
func assertMeasurementEnvironment() {
    #if DEBUG
    assertionFailure("Debug 빌드에서 성능을 측정하고 있습니다")
    #endif
    #if targetEnvironment(simulator)
    fatalError("시뮬레이터에서 성능을 측정하고 있습니다")   // assertionFailure는 -O에서 사라져 Release 측정 실수를 못 잡는다
    #endif
}

// ✅ 예외: 시뮬레이터가 유효한 경우
//    · 알고리즘 복잡도 비교 (상대 비교만)
//    · 메모리 누수·순환 참조 검출
//    · 로직 정확성
//    → "상대적으로 어느 쪽이 나은가"는 볼 수 있지만
//      "이 기기에서 몇 ms인가"는 볼 수 없다

// ✅ 실사용자 분포는 MetricKit으로 수집한다 — 가장 신뢰할 수 있는 수치다
//    MXAppLaunchMetric, MXAnimationMetric, MXMemoryMetric