feat: add test

[Balamurugan-100]

No description provided.

[claude]

Claude finished @Balamurugan-100's task in 3m 56s —— View job

---

Claude's Review

Tasks

• Gather context (read CLAUDE.md — none present; diff vs origin/main)
• Review code quality (force-unwraps, weak self, TPStreamPlayerError usage)
• Review resource lifecycle (KVO/time observers, deinit cleanup, Realm threading)
• Review public API / backward compatibility (#if SPM/CocoaPods guards, TPStreamPlayerConfiguration)
• Review security (tokens in logs/Sentry, DRM key exposure)
• Post review

This PR is overwhelmingly a test-suite addition (44 files, +6220/-44): 20+ new unit/integration test files, mock network/URLProtocol infrastructure for SampleAppIntegrationTests, a TEST_SUITE_GUIDE.md, an expanded two-job (pr-gate/release-gate) CI workflow, and a handful of small production-code tweaks to make the SDK testable. No public API surface changed in a breaking way, and I found no token/DRM-key leakage into logs or Sentry.

Critical — build-breaking duplicate Xcode project entries
iOSPlayerSDK.xcodeproj/project.pbxproj: 5 test files (TimeStringTests.swift, StreamsAPIParserTests.swift, TPStreamsDownloadManagerUnitTests.swift, TPAVPlayerUnitTests.swift, EncryptionKeyDelegateTests.swift) each have two PBXFileReference/PBXBuildFile entries pointing at the same on-disk file, and both are listed in the iOSPlayerSDKTests target's single Sources build phase. Compiling the same file twice into one target will fail xcodebuild test in CI (see inline comment for exact line numbers/IDs). This should be fixed before merge — I'd expect the pr-gate job to currently fail.

Other findings (inline comments posted)

• Source/Network/BaseAPI.swift:14 — new static var session: Session = AF test seam looks unused; SampleAppIntegrationTests mocks networking via global URLProtocol.registerClass instead, so this is dead code (or a wiring gap).
• Source/TPStreamsSDK.swift:40 — realmConfig changed from let to var to support configureInMemoryRealm in tests. Reasonable (internal-only, no public API break), just flagging it as a shared mutable global that could race under parallel test execution.
• .github/workflows/ios_test.yml:64 — release-gate's "Full Test Suite" step is identical to pr-gate's (same simulator destination), so it doesn't actually add device-dependent DRM/Keychain/download coverage as the comment/report claims — those tests self-skip on simulator per TEST_SUITE_GUIDE.md.

Nice catch

• Source/Utils/Time.swift:11 — guard seconds.isFinite || !seconds.isNaN → guard seconds.isFinite, !seconds.isNaN fixes a real bug: the old || condition let .infinity slip past the guard (only NaN was actually caught). Good fix.

I was unable to run xcodebuild/the test suite myself (no macOS/Xcode toolchain available in this environment), so I could not execute the new tests to confirm they pass beyond the static project-file analysis above.

[claude]

Critical: duplicate PBXBuildFile/PBXFileReference entries — this will break the build.

Five test files are each referenced twice by separate PBXFileReferences and compiled twice into the same iOSPlayerSDKTests target's Sources build phase (this phase, 8EDE99AA2A2643B000E43EA9):

• TimeStringTests.swift — build files D73F86A1... (fileRef D59FE315...) and F85EAAE2... (fileRef D9184752...), both listed at lines 996 & 1028
• StreamsAPIParserTests.swift — 1096D9CA.../098425DC... and 2803F4BE.../102E875A..., lines 997 & 1017
• TPStreamsDownloadManagerUnitTests.swift — 0F03D584.../9170F2A5... and FE102F81.../B91AE02F..., lines 998 & 1024
• TPAVPlayerUnitTests.swift — 6D20613A.../26838F8E... and B8BEE38F.../DF966C95..., lines 999 & 1019
• EncryptionKeyDelegateTests.swift — 6D714567.../373AC5A0... and AEE26E08.../50AA8F98..., lines 1000 & 1007

There is only one physical copy of each file on disk (in Tests/), so both PBXFileReferences point at the same file. Compiling the same Swift file twice into one target causes Xcode to fail with a "Multiple commands produce ...” / duplicate-symbol build error, which will fail the CI pr-gate/release-gate jobs entirely.

Fix: remove one PBXFileReference + matching PBXBuildFile entry for each of the 5 files (and its single duplicate line from this Sources phase), keeping only one.

Fix this →

[claude]

This new static var session: Session = AF seam appears unused — none of the new test files (Tests/, SampleAppIntegrationTests/) actually override BaseAPI.session. SampleAppIntegrationTests mocks the network via global URLProtocol.registerClass(MockURLProtocol.self) instead (see SampleAppIntegrationTests/MockURLProtocol.swift), which already intercepts AF's default session, making this injection point dead code. Either wire a test into it or drop it to avoid an unused, mutable global Session in production code (also worth a [weak self]-style guard/reset note: a global mutable static var used only by some future test could leak state across test runs if ever adopted without a teardown).

[claude]

Changing realmConfig from let to var so Tests/TestHelpers.swift:configureInMemoryRealm can swap in an in-memory config is reasonable for testability, but note it's a process-wide mutable global now (internal, not public, so no API-compat concern). If the test target ever enables parallel test execution, concurrent test classes mutating this shared static could race/flake. Not a blocker, just worth a // test-only mutation point note or restricting the setter, since ObjectManager.swift:12 reads it on every Realm access.

[claude]

The release-gate job's "Full Test Suite" step re-runs the identical xcodebuild test command as pr-gate — same scheme, same platform=iOS Simulator destination — so it does not actually add device-dependent coverage despite the comment "Adds: Full test suite (including device-dependent tests)". Per TEST_SUITE_GUIDE.md, DRM/AES/Keychain/offline-download tests are runtime-skipped on simulator via #if targetEnvironment(simulator)/isSimulator guards, so they'll silently no-op here too. The closing "Report" step then prints "✅ Unit tests: 384+ passing" / "SDK is ready for client handoff", which overstates coverage since the device-only tests never ran. Consider either running this job on a real device runner (self-hosted/cloud) or rewording the job description and report to make clear device-only tests are still not covered by CI.