Skip to content

CXD-1045: Demo apps conform to CLXTestHarnessApp settings-mutation API#68

Open
bryanboyko wants to merge 2 commits into
mainfrom
feature/test-harness-settings-mutation-support
Open

CXD-1045: Demo apps conform to CLXTestHarnessApp settings-mutation API#68
bryanboyko wants to merge 2 commits into
mainfrom
feature/test-harness-settings-mutation-support

Conversation

@bryanboyko

Copy link
Copy Markdown
Member

Summary

Adds -applySettingsMutation:params:error: and -verifyCleanState: conformance to both the Objective-C and Swift demo apps so the QA harness can drive the settings-mutation matrix (touchpoint C of the new release-QA sweep) without XCUITest.

Mutation IDs implemented in both apps:

  • gdpr_applies — sets IAB GDPR NSUserDefaults keys + CLXManualPrivacyState.hasUserConsent.
  • us_privacy — sets IABUSPrivacy_String.
  • hashed_user_id — calls [CloudXCore shared] setHashedUserID:.
  • user_kv_add / app_kv_add — calls setUserKeyValue:value: / setAppKeyValue:value:.
  • clear_all_kvs — calls clearAllKeyValues.
  • user_targeting_off — clears all KVs as the observable equivalent of disabled targeting (no first-class API yet).
  • hi_roi_targeting_signals — fans params out across user and app KVs.

verifyCleanState asserts CLXManualPrivacyState.hasUserConsent/doNotSell are both nil, CLXKeyValueState.hashedUserId is empty, user and app KV dictionaries are empty, and none of the IAB GDPR/CCPA NSUserDefaults keys are set. Any violation short-circuits with a descriptive NSError / Swift throws so the harness can classify the row as test_infra and move on.

Requires CloudXCore 3.1.0 or newer for the CLXKeyValueState / CLXManualPrivacyState accessors; the demo apps are already pinned to 3.1.0 on main.

Paired PRs

  • cloudx-io/cloudx-qa-automation feature/qa-automation-expansion (protocol extension + orchestrator).
  • cloudx-io/cloudx-ios-private docs/release-md-qa-orchestrator (RELEASE.md Phase 3 wording).

Test plan

  • Lints clean on both files.
  • pod install + simulator build in both schemes (pending; primary unchecked risk is any signature mismatch against the live CloudXCore headers).
  • Manual deep-link smoke from the harness:
    • cloudxobjcremotepods://verify-clean-state produces CLX_CLEAN_STATE_RESULT {"ok":true} on a fresh install.
    • cloudxobjcremotepods://apply-mutation?id=us_privacy&params=<base64({"value":"1YNN"})> produces CLX_MUTATION_RESULT {"verdict":"pass"}.
  • Single settings-mutation-suite.sh row end-to-end once the qa-automation PR is merged.

Made with Cursor

Adds -applySettingsMutation:params:error: and -verifyCleanState: conformance
in both demo apps so the QA harness can drive the settings-mutation matrix
without XCUITest. Covers gdpr_applies, us_privacy, hashed_user_id,
user_kv_add, app_kv_add, clear_all_kvs, user_targeting_off, and
hi_roi_targeting_signals by calling CloudXCore's public privacy and
key-value APIs plus the IAB NSUserDefaults keys for GDPR/CCPA signals.

verifyCleanState inspects CLXManualPrivacyState, CLXKeyValueState, and the
IAB NSUserDefaults keys so no state leaks between mutation rows. Requires
CloudXCore 3.1.0 or newer for the CLXKeyValueState / CLXManualPrivacyState
accessors; the demo apps are already pinned to 3.1.0 on main.

Paired with the CLXTestHarnessApp protocol additions in the
cloudx-qa-automation feature branch.

Made-with: Cursor
@bryanboyko bryanboyko changed the title feat(demo-apps): conform to CLXTestHarnessApp settings-mutation API CXD-1045: Demo apps conform to CLXTestHarnessApp settings-mutation API Apr 17, 2026
DeepLinkRouter.swift used `CloudXCore.shared()` which fails to compile —
the ObjC `+ (instancetype)shared` bridges as a Swift property, not a
method. Changed to `CloudXCore.shared`.

Both demo Podfiles gain an opt-in `pod 'CloudXTestHarness'` line guarded
by `ENV['CLX_QA_HARNESS'] == '1'`. Normal dev and release builds are
unchanged (harness absent). The QA orchestrator sets the env var before
`pod install` so the adapter's `applySettingsMutation:` and
`verifyCleanState:` conformances get wired through the harness.

Podfile.lock updates reflect the existing `~> 3.1.0` pinning that was
already on `main` — no new SDK version bump.

Validated: both demo apps compile clean against CloudXCore 3.1.0 with
the harness linked locally.

Made-with: Cursor
@bryanboyko

Copy link
Copy Markdown
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant