Parallel usage of AlertVerifier and PresentationVerifier

[dudek-j]

There are a couple of scenarios in our app where a controller is presented directly from an alert action. We’d like to use AlertVerifier to trigger the action (implicitly verifying the button title) and, within the same test, inspect the presented controller.

@Test
func `example test`() throws {
    let sut = fixture()

    let alert = AlertVerifier()
    sut.showAlert()
    let presenter = PresentationVerifier()
    try alert.executeAction(forButton: "My Action")

    #expect(spy.presentedViewController is MyViewController)
}

This isn’t currently possible due to the mutually exclusive ownership of the present mock between AlertVerifier and PresentationVerifier.

I’ve put together a minimal change that allows both verifiers to operate simultaneously:
dudek-j@feef4d9

Is there a reason this approach wouldn’t be suitable for upstream adoption, or would you consider supporting this workflow?

Note: The fork introduces a behavioural change where presenting a UIAlertController no longer notifies PresentationVerifier. This can be adjusted if needed.

[jonreid]

Hi @dudek-j, this is interesting. Can you tell me more about the change in behavior in your "note"?

[dudek-j]

This test passes on the latest release but fails on the fork since PresentationVerifier is no longer notified for a UIAlertController.

@Test
func `example test`() {
    let presenter = PresentationVerifier()
    let controller = UIViewController()
    controller.present(UIAlertController())

    #expect(1 == presenter.presentedCount)
}

The fork could be adjusted to notify both verifiers, depending on the expected behaviour.

[jonreid]

Ahh okay. Let's think about this. To avoid breaking existing tests, we could notify both, as you suggest. Do you think it would help to make this an controllable setting, or not?

[dudek-j]

I don't think there is a need for the setting, not in our use case at least. Keeping the API simple and concise is preferable.

It also makes the tests a bit harder to interpret as you need to know the state of the setting to understand if an assert is correct or not. I would rather adjust the asserts to take into account all calls to present during the test.

[jonreid]

Sounds good. Can you open a PR? Don't worry about making it "perfect" at first, I consider the branch a place where we can iterate together.

Is there any clean-up the project needs before you make any changes?