search

moredip / PublicAutomation

Other
4 stars 22 forks source link

Taps not working #1

Closed drekka closed 11 years ago

drekka commented 11 years ago

Hi, I'm working with the TestingWithFrank fork of the repo to use it in Simon. I'm testing using GHUnit. The basic test is a GHUnit test that adds a UIView to the main window and then taps a button on that view.

However the tap never occurs. I've been looking into this and it could be the setup of the views. It appears that GHUnits interface creates the UIWindow, but never sets a rootViewController. The Simulator logs are error to the effect and debugging shows a nil value.

To perform the test, I add my test view as a subview of [UIApplication sharedApplication].keyWindow.

This has worked for testing up until this point.

PublicAutomation does not throw any error, and logs that it is tapping at what appears to be the correct location. But the button is never tapped.

Can you shed any light on this?

ciao Derek

moredip commented 11 years ago

Are the unit tests set up as Application Tests or Logic Tests? I wouldn't be surprised if they need to be Application Tests.

I have gotten a similar spike working using Kiwi and PublicAutomation. If you need I could dig it up and share with you.

Cheers,

Pete

Typed on a little bitty keyboard

On Dec 7, 2012, at 5:44 AM, Derek Clarkson notifications@github.com wrote:

Hi, I'm working with the TestingWithFrank fork of the repo to use it in Simon. I'm testing using GHUnit. The basic test is a GHUnit test that adds a UIView to the main window and then taps a button on that view.

However the tap never occurs. I've been looking into this and it could be the setup of the views. It appears that GHUnits interface creates the UIWindow, but never sets a rootViewController. The Simulator logs are error to the effect and debugging shows a nil value.

To perform the test, I add my test view as a subview of [UIApplication sharedApplication].keyWindow.

This has worked for testing up until this point.

PublicAutomation does not throw any error, and logs that it is tapping at what appears to be the correct location. But the button is never tapped.

Can you shed any light on this?

ciao Derek

— Reply to this email directly or view it on GitHub.

drekka commented 11 years ago

GHUnit tests. They run in the Simulator or device using a supplied runner. So in a sense application tests because they are running within an application.

Been doing some more testing. The test code is running on a background thread. I found that if I re-queued the tap on the main thread along with a call to the runloop to get it to fire, then it appears to work. So this looks like a threading issue. I'll play with it some more.

drekka commented 11 years ago

I think I have the angle on this. The way I was generating tap/swipe events meant that the event code was not returning until all touches had been sent to the UI. So effectively it was pausing the background thread for the duration of the event. Switching to the Public Automation based code, it appears that the private APIs queue the event generation and returns immediately. Therefore my following code can execute earlier, before the event gets a chance to occur on the UI. So my current plan is to introduced some standard pauses after generating events to give the UI a chance to execute.

Any opinion on this?

moredip commented 11 years ago

FWIW, Frank's approach to this is to avoid explicit sleeps if at all possible, and prefer to do 'spin asserts' waiting for the cue to proceed to the next testing step. http://sauceio.com/index.php/2011/04/how-to-lose-races-and-win-at-selenium/

We have helpers like 'wait for nothing to be animating'. Another very common need is 'wait for nav stack to finish animating'.

On Wednesday, December 19, 2012, Derek Clarkson wrote:

I think I have the angle on this. The way I was generating tap/swipe events meant that the event code was not returning until all touches had been sent to the UI. So effectively it was pausing the background thread for the duration of the event. With the UI automation code, it appears that it queues the touch event generation and returns immediately. Therefore my following code can be executing at the same time or before the event gets a chance to occur on the UI. So my current plan is to introduced some standard pauses after generating events to give the UI a chance to execute.

Any opinion on this?

— Reply to this email directly or view it on GitHubhttps://github.com/moredip/PublicAutomation/issues/1#issuecomment-11527730.

drekka commented 11 years ago

Hmm, I already have a waitfor functions which waits for a specific view to appear or for all animations in a view hierarchy to finish. I'll look into that approach further as I agree that pausing for a specific period of time is - ugly, and I've been holding off doing it because it just felt wrong.

drekka commented 11 years ago

Been working on the way Simon works in respect to sending events. Done lots of thinking and refactoring. Thanks for all your help.

moredip commented 11 years ago

Always glad to spur thinking an refactoring :)

Cheers,

Pete

Typed on a little bitty keyboard

On Jan 8, 2013, at 2:11 AM, Derek Clarkson notifications@github.com wrote:

Been working on the way Simon works in respect to sending events. Done lots of thinking and refactoring. Thanks for all your help.

— Reply to this email directly or view it on GitHub.