owncloud
[FEATURE REQUEST] QA Variant
It'd be cool to have a QA variant in the app that builds an artifact to be the input for the E2E tests.
The QA build is intended to be launched in a emulator, so, the artifact would be the owncloud.app file (not ipa) usually stored in $HOME/Library/Developer/Xcode/DerivedData/ownCloud-*/Build/Products/Debug-iphonesimulator after building.
Features:
- Set up for only basic auth (browser dependency is not easy to handle, i launch tests against servers with basic auth enabled)
- No release notes
- Beta build without beta warning
My current way to do this: an script that performs the following gsed (sed for macos) to modify the involved files:
gsed -i '136i OCConnectionAllowedAuthenticationMethodIDs : @[ OCAuthenticationMethodIdentifierBasicAuth ],' ios-sdk/ownCloudSDK/Connection/OCConnection.m`
gsed -i 's/.showBetaWarning : true/.showBetaWarning : false/i' ownCloudAppShared/Tools/VendorServices.swift
gsed -i 's/.isBetaBuild : false/.isBetaBuild : true/i' ownCloudAppShared/Tools/VendorServices.swift
gsed -i '170,200d' ownCloud/Release\ Notes/ReleaseNotesHostViewController.swift
And then, building the app:
xcrun xcodebuild clean -scheme "ownCloud"
xcrun xcodebuild \
-workspace ownCloud.xcworkspace \
-scheme ownCloud \
-configuration Debug \
-destination 'platform=iOS Simulator,name=iPhone 16'
If there is a way to compile a build variant that products the owncloud.app file with just a command, it'd be a good help to build it in a CI environment (github actions) to use it in the tests.
TASKS
- [ ] Research (if needed)
- [ ] Create branch feature/feature_name
- [ ] Development tasks
- [ ] Implement whatever
- [ ] ...
- [ ] Code review and apply changes requested
- [ ] Design test plan
- [ ] QA
- [ ] Merge branch feature/feature_name into master
PR
- App
- Library (if needed)
Off the top of my head I'd say the script you use is probably already the most efficient approach.
Alternatives I can think of:
- create a second target in the project, which essentially clones the app. Problem(s) here:
- keeping the regular app and the QA app target in sync (hard)
- if they aren't in sync, the QA app target will behave differently, thwarting the purpose So I think that's something we shouldn't do.
-
use
#ifs in the code and toggle them by passing respective parameters. I'd have to check if that's possible. But again, the overhead for implementing and maintaining this is probably higher than using a script like yours. -
if running the app via Xcode is ok, we could also implement a new MDM/class settings option to enable special QA build behavior. You can then switch to that behavior simply by toggling on/off an env variable in Xcode.
