@devicelab/maestro-runner-darwin-arm64 1.1.25 → 1.1.28

package/drivers/ios/devicelab-ios-agent/simulator/DevicelabIOSAgentUITests-Runner.app/Frameworks/XCTest.framework/Headers/XCTestCase+AsynchronousTesting.h

@@ -0,0 +1,276 @@
+#if __has_include(<XCTestCore/XCTestCase+AsynchronousTesting.h>)
+#import <XCTestCore/XCTestCase+AsynchronousTesting.h>
+#else
+
+//
+//  Copyright © 2014-2017 Apple Inc. All rights reserved.
+//
+
+#import <XCTest/XCTestCase.h>
+#import <XCTest/XCTestDefines.h>
+#import <XCTest/XCTWaiter.h>
+#import <XCTest/XCTKVOExpectation.h>
+#import <XCTest/XCTNSNotificationExpectation.h>
+#import <XCTest/XCTNSPredicateExpectation.h>
+
+@class XCTestExpectation;
+
+NS_ASSUME_NONNULL_BEGIN
+
+/*!
+ * @category AsynchronousTesting
+ *
+ * @discussion
+ * This category introduces support for asynchronous testing in XCTestCase. The mechanism
+ * allows you to specify one or more "expectations" that will occur asynchronously
+ * as a result of actions in the test. Once all expectations have been set, a "wait"
+ * API is called that will block execution of subsequent test code until all expected
+ * conditions have been fulfilled or a timeout occurs.
+ */
+@interface XCTestCase (AsynchronousTesting) <XCTWaiterDelegate>
+
+/*!
+ * @method -expectationWithDescription:
+ *
+ * @param description
+ * This string will be displayed in the test log to help diagnose failures.
+ *
+ * @discussion
+ * Creates and returns an expectation associated with the test case.
+ */
+- (XCTestExpectation *)expectationWithDescription:(NSString *)description XCT_WARN_UNUSED;
+
+/*!
+ * @typedef XCWaitCompletionHandler
+ * A block to be invoked when a call to -waitForExpectationsWithTimeout:handler: times out or has
+ * had all associated expectations fulfilled.
+ *
+ * @param error
+ * If the wait timed out or a failure was raised while waiting, the error's code
+ * will specify the type of failure. Otherwise error will be nil.
+ */
+typedef void (^XCWaitCompletionHandler)(NSError * _Nullable error);
+
+/*!
+ * @method -waitForExpectationsWithTimeout:handler:
+ *
+ * @param timeout
+ * The amount of time within which all expectations must be fulfilled.
+ *
+ * @param handler
+ * If provided, the handler will be invoked both on timeout or fulfillment of all
+ * expectations. Timeout is always treated as a test failure.
+ *
+ * @discussion
+ * -waitForExpectationsWithTimeout:handler: creates a point of synchronization in the flow of a
+ * test. Only one -waitForExpectationsWithTimeout:handler: can be active at any given time, but
+ * multiple discrete sequences of { expectations -> wait } can be chained together.
+ *
+ * -waitForExpectationsWithTimeout:handler: runs the run loop while handling events until all expectations
+ * are fulfilled or the timeout is reached. Clients should not manipulate the run
+ * loop while using this API.
+ */
+- (void)waitForExpectationsWithTimeout:(NSTimeInterval)timeout handler:(nullable XCT_SWIFT_SENDABLE XCWaitCompletionHandler)handler XCT_SWIFT_MAIN_ACTOR XCT_SWIFT_UNAVAILABLE_FROM_ASYNC("Use await fulfillment(of:timeout:enforceOrder:) instead");
+
+/*!
+ * @method -waitForExpectations:
+ *
+ * Waits on a group of expectations indefinitely.
+ *
+ * @param expectations
+ * An array of expectations that must be fulfilled.
+ *
+ * @discussion
+ * The test will continue to run until @a expectations are fulfilled or the
+ * test reaches its execution time allowance.
+ *
+ * Expectations can only appear in the list once. This method may return
+ * early based on fulfillment of the provided expectations.
+ *
+ * Enabling test timeouts is recommended when using this method to prevent a
+ * runaway expectation from hanging the test.
+ */
+- (void)waitForExpectations:(NSArray<XCTestExpectation *> *)expectations XCT_SWIFT_UNAVAILABLE_FROM_ASYNC("Use await fulfillment(of:timeout:enforceOrder:) instead");
+
+/*!
+ * @method -waitForExpectations:timeout:
+ *
+ * Waits on a group of expectations for up to the specified timeout.
+ *
+ * @param expectations
+ * An array of expectations that must be fulfilled.
+ *
+ * @param seconds
+ * The number of seconds within which all expectations must be fulfilled.
+ *
+ * @discussion
+ * Expectations can only appear in the list once. This method may return
+ * early based on fulfillment of the provided expectations.
+ */
+- (void)waitForExpectations:(NSArray<XCTestExpectation *> *)expectations timeout:(NSTimeInterval)seconds XCT_SWIFT_UNAVAILABLE_FROM_ASYNC("Use await fulfillment(of:timeout:enforceOrder:) instead");
+
+/*!
+ * @method -waitForExpectations:enforceOrder:
+ *
+ * Waits on a group of expectations indefinitely, optionally enforcing their
+ * order of fulfillment.
+ *
+ * @param expectations
+ * An array of expectations that must be fulfilled.
+ *
+ * @param enforceOrderOfFulfillment
+ * If @c YES, the expectations specified by the @a expectations parameter must
+ * be satisfied in the order they appear in the array.
+ *
+ * @discussion
+ * The test will continue to run until @a expectations are fulfilled or the
+ * test reaches its execution time allowance.
+ *
+ * Expectations can only appear in the list once. This method may return
+ * early based on fulfillment of the provided expectations.
+ *
+ * Enabling test timeouts is recommended when using this method to prevent a
+ * runaway expectation from hanging the test.
+ */
+- (void)waitForExpectations:(NSArray<XCTestExpectation *> *)expectations enforceOrder:(BOOL)enforceOrderOfFulfillment XCT_SWIFT_UNAVAILABLE_FROM_ASYNC("Use await fulfillment(of:timeout:enforceOrder:) instead");
+
+/*!
+ * @method -waitForExpectations:timeout:enforceOrder:
+ *
+ * Waits on a group of expectations for up to the specified timeout, optionally
+ * enforcing their order of fulfillment.
+ *
+ * @param expectations
+ * An array of expectations that must be fulfilled.
+ *
+ * @param seconds
+ * The number of seconds within which all expectations must be fulfilled.
+ *
+ * @param enforceOrderOfFulfillment
+ * If @c YES, the expectations specified by the @a expectations parameter must
+ * be satisfied in the order they appear in the array.
+ *
+ * @discussion
+ * Expectations can only appear in the list once. This method may return
+ * early based on fulfillment of the provided expectations.
+ */
+- (void)waitForExpectations:(NSArray<XCTestExpectation *> *)expectations timeout:(NSTimeInterval)seconds enforceOrder:(BOOL)enforceOrderOfFulfillment XCT_SWIFT_UNAVAILABLE_FROM_ASYNC("Use await fulfillment(of:timeout:enforceOrder:) instead");
+
+#pragma mark Convenience APIs
+
+/*!
+ * @method -keyValueObservingExpectationForObject:keyPath:expectedValue:
+ *
+ * @discussion
+ * A convenience method for asynchronous tests that use Key Value Observing to detect changes
+ * to values on an object. This variant takes an expected value and observes changes on the object
+ * until the keyPath's value matches the expected value using -[NSObject isEqual:]. If
+ * other comparisons are needed, use the variant below that takes a handler block.
+ *
+ * @param objectToObserve
+ * The object to observe.
+ *
+ * @param keyPath
+ * The key path to observe.
+ *
+ * @param expectedValue
+ * Expected value of the keyPath for the object. The expectation will fulfill itself when the
+ * keyPath is equal, as tested using -[NSObject isEqual:]. If nil, the expectation will be
+ * fulfilled by the first change to the key path of the observed object.
+ *
+ * @return
+ * Creates and returns an expectation associated with the test case.
+ */
+- (XCTestExpectation *)keyValueObservingExpectationForObject:(id)objectToObserve keyPath:(NSString *)keyPath expectedValue:(nullable id)expectedValue
+XCT_TO_BE_DEPRECATED_WITH_SWIFT_REPLACEMENT("expectation(that:on:options:willEqual:)");
+
+/*!
+ * @method -keyValueObservingExpectationForObject:keyPath:handler:
+ *
+ * @discussion
+ * Variant of the convenience for tests that use Key Value Observing. Takes a handler
+ * block instead of an expected value. Every KVO change will run the handler block until
+ * it returns YES (or the wait times out). Returning YES from the block will fulfill the
+ * expectation. XCTAssert and related APIs can be used in the block to report a failure.
+ *
+ * @param objectToObserve
+ * The object to observe.
+ *
+ * @param keyPath
+ * The key path to observe.
+ *
+ * @param handler
+ * Optional handler, /see XCKeyValueObservingExpectationHandler. If not provided, the expectation will
+ * be fulfilled by the first change to the key path of the observed object.
+ *
+ * @return
+ * Creates and returns an expectation associated with the test case.
+ */
+- (XCTestExpectation *)keyValueObservingExpectationForObject:(id)objectToObserve keyPath:(NSString *)keyPath handler:(nullable XCKeyValueObservingExpectationHandler)handler
+XCT_TO_BE_DEPRECATED_WITH_SWIFT_REPLACEMENT("expectation(that:on:options:willSatisfy:)");
+
+/*!
+ * @method -expectationForNotification:object:handler:
+ *
+ * @discussion
+ * A convenience method for asynchronous tests that observe NSNotifications from the default
+ * NSNotificationCenter.
+ *
+ * @param notificationName
+ * The notification to register for.
+ *
+ * @param objectToObserve
+ * The object to observe.
+ *
+ * @param handler
+ * Optional handler, /see XCNotificationExpectationHandler. If not provided, the expectation
+ * will be fulfilled by the first notification matching the specified name from the
+ * observed object.
+ *
+ * @return
+ * Creates and returns an expectation associated with the test case.
+ */
+- (XCTestExpectation *)expectationForNotification:(NSNotificationName)notificationName object:(nullable id)objectToObserve handler:(nullable XCNotificationExpectationHandler)handler;
+
+/*!
+ * @method -expectationForNotification:object:notificationCenter:handler:
+ *
+ * @discussion
+ * A convenience method for asynchronous tests that observe NSNotifications from a specific
+ * NSNotificationCenter.
+ *
+ * @param notificationName
+ * The notification to register for.
+ *
+ * @param objectToObserve
+ * The object to observe.
+ *
+ * @param notificationCenter
+ * The notification center from which to observe the notification.
+ *
+ * @param handler
+ * Optional handler, /see XCNotificationExpectationHandler. If not provided, the expectation
+ * will be fulfilled by the first notification matching the specified name from the
+ * observed object.
+ *
+ * @return
+ * Creates and returns an expectation associated with the test case.
+ */
+- (XCTestExpectation *)expectationForNotification:(NSNotificationName)notificationName object:(nullable id)objectToObserve notificationCenter:(NSNotificationCenter *)notificationCenter handler:(nullable XCNotificationExpectationHandler)handler;
+
+/*!
+ * @method -expectationForPredicate:evaluatedWithObject:handler:
+ * Creates an expectation that is fulfilled if the predicate returns true when evaluated with the given
+ * object. The expectation periodically evaluates the predicate and also may use notifications or other
+ * events to optimistically re-evaluate.
+ *
+ * When the resulting expectation is used from Swift and is awaited using @c fulfillment(of:) rather
+ * than @c wait(for:), XCTest evaluates @a predicate on the main actor.
+ */
+- (XCTestExpectation *)expectationForPredicate:(NSPredicate *)predicate evaluatedWithObject:(nullable id)object handler:(nullable XCPredicateExpectationHandler)handler;
+
+@end
+
+NS_ASSUME_NONNULL_END
+
+#endif

package/drivers/ios/devicelab-ios-agent/simulator/DevicelabIOSAgentUITests-Runner.app/Frameworks/XCTest.framework/Headers/XCTestCase+XCUIApplicationLaunchTesting.h

@@ -0,0 +1,36 @@
+//
+//  Copyright © 2021 Apple Inc. All rights reserved.
+//
+
+#import <XCTest/XCTestDefines.h>
+#import <XCTest/XCTestCase.h>
+
+#if XCT_UI_TESTING_AVAILABLE
+
+NS_ASSUME_NONNULL_BEGIN
+
+XCT_SWIFT_MAIN_ACTOR
+@interface XCTestCase (XCUIApplication_LaunchTesting)
+
+/// Determines whether the tests in this class should run multiple times, once for each of the target application's UI configurations.
+///
+/// Returns false by default. If overridden in a UI test subclass to return true, each test in that
+/// class will run multiple times, once for each supported UI configuration of the default target application.
+///
+/// Supported UI configurations are detected by Xcode according to the settings of the default target app
+/// for the UI test target and may include:
+///
+/// - Appearances (e.g. light mode, dark mode)
+/// - Orientations (e.g. portrait, landscape)
+/// - Localizations (e.g. en_US, zh_CN)
+///
+/// Given the above example, one UI configuration would be {dark mode, landscape, en_US}, another would be
+/// {light mode, portrait, zh_CN}, and so forth. The number of combinations determines the number of times each
+/// test will run. The UI configuration is used automatically when calling `XCUIApplication.launch()` in each test.
+@property (class, readonly) BOOL runsForEachTargetApplicationUIConfiguration;
+
+@end
+
+NS_ASSUME_NONNULL_END
+
+#endif // XCT_UI_TESTING_AVAILABLE

package/drivers/ios/devicelab-ios-agent/simulator/DevicelabIOSAgentUITests-Runner.app/Frameworks/XCTest.framework/Headers/XCTestCase+XCUIInterruptionMonitoring.h

@@ -0,0 +1,95 @@
+//
+//  Copyright © 2019 Apple Inc. All rights reserved.
+//
+
+#import <XCTest/XCTestDefines.h>
+#import <XCTest/XCTestCase.h>
+
+#if XCT_UI_TESTING_AVAILABLE
+
+NS_ASSUME_NONNULL_BEGIN
+
+@class XCUIElement;
+
+XCT_SWIFT_MAIN_ACTOR
+@interface XCTestCase (XCUIInterruptionMonitoring)
+
+/*!
+ * @method addUIInterruptionMonitorWithDescription:handler:
+ *
+ * @abstract Adds a monitor to the test. Monitors are automatically removed at the end of the test or can be manually removed using -removeUIInterruptionMonitor:.
+ * Monitors are invoked in the reverse order in which they are added until one of the monitors returns true, indicating that it has handled the interruption.
+ *
+ * @param handlerDescription
+ * Explanation of the behavior and purpose of this monitor, mainly used for debugging and analysis.
+ *
+ * @param handler
+ * Handler block for asynchronous, non-deterministic interrupting UI such as alerts and other dialogs. Handlers should return true if they handled the UI, false if they did not.
+ * The handler is passed an XCUIElement representing the top level UI element for the alert.
+ *
+ * @return Returns an opaque token that can be used to remove the monitor.
+ *
+ * @discussion
+ * A "UI interruption" is any element which unexpectedly blocks access to an element with which a UI test is trying to interact. Interrupting elements are most commonly alerts,
+ * dialogs, or other windows, but can be of other types as well. Interruptions are unexpected or at least not deterministic: the appearance of an alert in direct response to
+ * a test action such as clicking a button is not an interruption and should not be handled using a UI interruption monitor. Instead, it's simply part of the UI and should be
+ * found using standard queries and interacted with using standard event methods. Note that some interruptions are part of the app's own UI, others are presented on
+ * behalf of system apps and services, so queries for these elements must be constructed with the right process at their root.
+ *
+ * Use a UI interruption monitor for alerts that appear unexpectedly or with non-deterministic timing. Monitors are not invoked simply by the appearance of an alert or similar
+ * UI, they are called when the presence of such UI interferes with actions the test is attempting to take. For example, consider the following sequence:
+ *
+ * - test taps button
+ * - app displays confirmation dialog
+ *
+ * In this case, the dialog that is presented can be anticipated by the test, so a UI interruption monitor should not be used. Instead, the sequence should look like:
+ *
+ * - test taps button
+ * - test constructs an XCUIElement for the dialog and uses XCUIElement.waitForExistence(timeout:) to wait for it to appear
+ * - app displays confirmation dialog
+ * - test synthesizes a tap for the appropriate button in the dialog
+ * - test continues execution
+ *
+ * There was no UI interruption in this example because every step was deterministic and known in advance. Note the use of XCUIElement.waitForExistence(timeout:) to deal with
+ * asynchronous delays in the display of the dialog.
+ *
+ * By contrast, consider the next sequence, where use of a UI interruption monitor is the correct solution:
+ *
+ * - test launches app
+ * - app initiates asynchronous network request
+ * - test interacts with app
+ * - network request completes, app decides to display a dialog to the user
+ * - dialog appears just as the test is about to tap on a button
+ *      - the appearance of the dialog is not deterministic
+ *      - the test can anticipate that the dialog might be displayed at some point, but not when
+ *      - accordingly, the test has installed a UI interruption monitor that knows how to handle the network response dialog
+ * - when XCTest computes a hit point for the button, it discovers the dialog and treats it as "interrupting UI"
+ * - the previously installed UI interruption monitor is invoked
+ * - it handles the dialog
+ * - XCTest computes the hit point for the button and synthesizes the requested tap event
+ * - test execution continues...
+ *
+ * Monitors can be designed to be general or specific in how they handle interruptions. The simplest general approach might simply attempt to cancel/dismiss/close
+ * any interrupting dialog/alert/window without consideration for its contents or purpose. A more specific monitor might make decisions based on the UI and contents
+ * of the interruption. Tests may install multiple monitors, which will be invoked in reverse order of installation. If a more specific monitor wishes to be skipped for a
+ * given interruption, its handler can simply return false - the next monitor will be invoked, and so on, until one of them returns true, signifying that it has handled
+ * the interruption. In some cases, a default monitor may handle interruptions.
+ */
+- (id<NSObject>)addUIInterruptionMonitorWithDescription:(NSString *)handlerDescription
+                                                handler:(BOOL (^)(XCUIElement *interruptingElement))handler;
+
+/*!
+ * @method removeUIInterruptionMonitor:
+ * 
+ * @abstract Removes a monitor using the token provided when it was added.
+ *
+ * @param monitor
+ * The token representing the monitor returned from the call to addUIInterruptionMonitorWithDescription:handler: where it was registered.
+ */
+- (void)removeUIInterruptionMonitor:(id<NSObject>)monitor;
+
+@end
+
+NS_ASSUME_NONNULL_END
+
+#endif // XCT_UI_TESTING_AVAILABLE