Clarify the use of contexts:
- **Production** (.shared)
- **Previews** (.mock → .forPreviews)
- ONLY use it in UILibrary for, well, previews
- This context has dumb profiles with UUIDs as names
- Registry is fake
- **UI Tests** (.forUITesting)
- Add new context for UI testing
- Selected based on command line arguments
- This context has mock data tuned for decent screenshots
- Registry is real
Share the same InAppProcessor in .shared and .forTesting contexts
because the app behavior was inconsistent regarding e.g. in-app
purchases.
Create UITesting target with:
- AppCommandLine/AppEnvironment: strongly typed refactoring of PP_*
environment values
- AccessibilityInfo: identifies and locates elements for UI testing
Make the app behave differently when launched with `.uiTesting`, and
expose the flag to SwiftUI via `.environment(\.isUITesting)` to:
- Use the mock AppContext
- Skip onboarding
Add PassepartoutUITests target with two screenshot tests:
- Connected screen
- Profile modal
To get access to modules, try to avoid full Profile objects. Instead,
replace the coupled ProfileHeader occurrences with a new intermediary
ProfilePreview everywhere.
This way, a ProfileProcessor can inject the localized modules
descriptions from above with the preview() method.
Streamline initialization of AppContext objects without singletons,
especially because some are interconnected.
Rethink ProfileProcessor to be the only gateway of profile processing
for:
- Include
- Save
- Connect
Provide closures with access to the IAPManager for eligibility checks.
Finally, take a ProfileProcessor parameter in:
- ProfileManager (for isIncluded and willSave)
- ExtendedTunnel (for willConnect)
so that it's used implicitly without having to put it into the SwiftUI
environment.
Other than that:
- Move AppError to CommonLibrary
- Skip decoding of attributes from Core Data because they are already
part of the profile
Davide