Thank you for creating Hammer!

I’d like to tap on an item in the callout bar, which lives in the text effects window. This is what I have so far:

let textEffectsWindow = UIApplication.textEffectsWindow /// A helper I wrote.
textEffectsWindow.makeKey() /// Otherwise, initializing an EventGenerator on the next line will throw.
let eventGeneratorForTextEffectsWindow = try EventGenerator(window: textEffectsWindow)
let linkButton = try eventGeneratorForTextEffectsWindow.viewWithLabel("Link") /// A helper I wrote to get a view by its `accessibilityLabel`.
try eventGeneratorForTextEffectsWindow.fingerDown(at: linkButton) /// This line throws `HammerError.viewIsNotHittable`.
try eventGeneratorForTextEffectsWindow.fingerUp()
window.makeKey() /// Makes my main window key again so I can proceed with my test.

fingerDown(at:) throws on line 264 of Subviews.swift since self.window.hitTest(hitPoint, with: nil) returns the entire UICalloutBar, not the UICalloutBarButton linkButton. Do you have any experience with the callout bar?

Thank you!

Describe the bug A view is deemed "not visible" by the library upon finger tap, even if the view is visible but outside the superview's bounds.

To Reproduce Steps to reproduce the behavior:

1. Create a tappable view outside superview's bounds. (with superview.clipsToBounds = false)
2. try to tap the view using fingerTap(at:)
3. .viewIsNotVisible error is thrown

Expected behavior View should be hittable.

Screenshots If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• Device: iPhone 13 Pro Max
• OS: iOS 15

Additional context Bug is pretty clear and easy to reproduce. Below is the problematic condition.

func isVisible(_ rect: CGRect, visibility: EventGenerator.Visibility = .partial) -> Bool {
        switch visibility {
        case .partial:
            return self.intersects(rect)
        case .center:
            return self.contains(rect.center)
        case .full:
            return self.contains(rect)
        }
}

Describe the bug Xcode 13.3 can't compile an App-project which contains Hammer 0.14.0

To Reproduce

1. Create new project with Xcode 13.3
2. Add Hammer as depedency
3. Build this project
4. see compiler error

• https://raw.githubusercontent.com/awBSH/lyft-hammer-xcode13.3/main/EventGenerator%2BMarker.swift.txt
• https://raw.githubusercontent.com/awBSH/lyft-hammer-xcode13.3/main/KeyboardKey.swift.txt

Expected behavior Project builds successfully with Hammer

Screenshots

Environment (please complete the following information):

• Device: MacBook Pro M1 Pro
• OS: macOS 12.3

Additional context We have added a sample project in https://github.com/awBSH/lyft-hammer-xcode13.3

@gabriellanata Hey buddy,

There is a a bug in fingerUp where the location in touchesEnded callback is the start position of the drag(e.g. fingerDown). It is because FingerInfo only holds the initial location of the finger, so when I call fingerUp, it will cause the final touch on the initial point, not where the drag has ended.

To reproduce, comment out this line and run the DragTests I put in.

Once again, I greatly appreciate this library you put together. It has opened up fantastic automated testing suites for my app.

We are bringing in Hammer via Swift PM and including it under Build Phases > Link Binary With Libraries for a test target.

Our project compiles fine under Xcode 12.5.1 but with Xcode 13 beta 4 I get a compiler error about Hammer’s use of UIApplication.shared:

'shared' is unavailable in application extensions for iOS: Use view controller based solutions where appropriate instead.

I tried cloning Hammer and compiling it for an iOS 15 sim and hit the same error.

Hey there,

I started seeing new type of warning logs as I generate touch events. However it doesn't seem to affect the functionality. Do you know why this started happening?

2022-07-22 14:38:11.471364-0400 IntegrationTestHost[36563:3464107] [EventDispatcher] Found no UIEvent for backing event of type: 1; contextId: 0x9DE5CC17; Event will not be dispatched
2022-07-22 14:38:11.473324-0400 IntegrationTestHost[36563:3464107] [EventDispatcher] Found no UIEvent for backing event of type: 1; contextId: 0x9DE5CC17; Event will not be dispatched
2022-07-22 14:38:11.491951-0400 IntegrationTestHost[36563:3464107] [EventDispatcher] Found no UIEvent for backing event of type: 1; contextId: 0x9DE5CC17; Event will not be dispatched

Another question I have is how are you guys handling the flakiness for Hammer in testing. Although not very often, my tests which rely on using Hammer shows flakiness in CI build machines. Do you encounter similar problems? Do you have any tips on how to mitigate it?

Thanks in advance @gabriellanata

This method is deprecated but we still need to use it because iOS uses it itself and we need it to detect when the app is ignoring events. The fix is to add a protocol to bypass the warning.

Currently, when you initialize an event generator from a UIView, it adds that view directly to a UIWindow. This can be a destructive change because the view might already be a subview of another view (possibly even already added to a window) and it will get removed.

This change detects if the view already has a window and uses that directly. If not, it will get the top level superview by transversing the view hierarchy and use that instead. Because we set the mainView to the view that was passed in the initializer, everything else remains the same and it should not be a breaking change.

NOTE: This is possibly a breaking change for some cases where the view was getting removed from its original superview. This should be very rare and should have been considered a bug in the first place.

The visibility check was not taking into account the clipsToBounds property so it was often returning the wrong error (it should have passed the visibility check but not the hittable check).

Fixes #38

ScrollViews seem to be a little inconsistent when they start scrolling. The gesture detection requires a few points of travel to begin detecting, but the exact time the detection begins seems to vary, meaning that the scroll amount is not precise. Fixing by making the check allow for a bigger variation

Key window is an unnecessary requirement for touches so I'm moving the check only to keyboard events. In many cases, the window will become key by itself when tapped, but we don't need to enforce that.

I wonder if you ever got Hammer to work with SwiftUI Lists. We've played around with the .accessibiliy(identifier:) View modifier and that has worked for creating UI Tests within Xcode, however when we tried to locate the Lists with Hammer we seem to have found that no UIViews in the view hierarchy are given the accessibility identifiers we gave to the List Views.

Just to move forward, I've used the .accessibility(label:) view modifier as well and written an extension on UIView which recursively hunts all subviews for the first UIView matching a given test and tested the UIView.accessibilityLabel instead. At least once the UIView is identified we can then use it with Hammer.

Have you folks tried hunting SwiftUI-built objects much and had you found Lists don't play nicely?

Hi! Thanks for putting together this library, more ways to avoid scenario tests but still tap around are great! :D

Question here more than an issue: currently, this can only be used with UIKit views (it seems), but this could be extended to WatchKit, right? Is that something that you've attempted before? Thanks!