I've started using Firebase Test Lab recently with espresso. All the test cases pass on my local device but when it comes to testing devices present on google cloud, some test cases fail with exceptions like "NoMatchingViewException". I've tried increasing the wait time before the test runs and the fragment loads, but that too does not seem to help. Please help if you know how to resolve this issue. Thank you!
I had the same problem when I tried my app. The problem is that I used UDPSocket in my application.. kinda weird but there was this exception thrown : NoMatchingViewException.
So, I Mocked the UDP call. So at least I was able to do the UI automated test.
Related
I have an Ionic app that correctly works in the IonicLab, both while running and debugging it.
The same code, when run or debugged on a real Android device, fails to initialize the argument in one of the then() callbacks of an Observable. Most other (I suspect all other) Observable instances around my code do work correctly.
If I were to guess the cause, I'd say that non-working-on-real-device Observable is too nested into a chain of enclosing Promises, but that's just a random guess by a random Angular newbie.
Here is what I see when I debug the app attached to the real Android device:
As you can see, the profile variable is undefined, but, as I understand how Observable.then() works, it should have a value, as it in fact does have when run in the IonicLab.
What am I missing?
I am writing instrumentation tests using Square's MockWebServer to mock server responses and OkHttpIdlingResource to wait for OkHttp to finish work until the remaining test steps continue. I am also using a MockWebServer dispatcher so that I can respond to certain requests differently depending on the path.
I am running into an issue where the tests work for some Android API versions and they don't work for others.
On Marshmallow the tests pass as expected. When I run on Android Pie, the MockWebServer responds to several requests, but then, for some reason, OkHttp throws a java.net.ConnectException.
If I hit my real web server everything works fine for any app version, it's only when using MockWebServer that I see this issue.
I have no idea what would cause this and the logs are not surfacing anything useful. In the failure case I can see that the MockWebServer has several successful 200 responses, but for some reason a ConnectException occurs during one of the calls.
The only weird thing I can see in the logs is that an Espresso ViewAssertion is logged before the last, failing, OkHttp request is logged. So it may be that the OkHttpIdlingResource is saying that it is idle when it really isn't.
Any ideas on what could be wrong?
I'm writing an espresso test for a login activity that sets cookies:
CookieManager.getInstance().setCookie(name, value)
But the test hangs at the above code then times out. Looking into the setCookie code I think it calls some native jni method.
I can't try setCookie(name, value, callback) because the code needs to support API level 19.
Any idea why this is happening?
Many thanks!
Update: just to add that this seems to only happen when test is run against emulator. It runs without problem against a real device.
My Android app uses the AWS Java SDK for uploading user photos to S3.
Whenever a user's phone's clock is 'skewed', this causes all transfers to fail. This is a well documented aspect of S3:
http://aws.amazon.com/articles/1109?_encoding=UTF8&jiveRedirect=1#04
It appears that the upstream S3 service reports this error quite clearly:
HTTP Status Code: 403 Forbidden
Error Code: RequestTimeToo-Skewed
Description: The difference between the request time and the server's
time is too large.
However when using the Java SDK, it seems as if the informative 403 code is lost ... and I have only an opaque "TransferState.Failed" to go by (which incidentally is the same error if internet connectivity is lost, if it times out, etc...).
As far as I can tell from the docs:
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/index.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/TransferProgress.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/Transfer.TransferState.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/Upload.html
There is no way to get the additional "RequestTimeToo-Skewed" metadata about a transfer failure.
Am I missing it? Is there any way to get additional error information when an S3 transfer fails using Amazon's Java SDK?
UPDATE #1:
A commenter kindly highlighted that I should clarity two points:
I am actually using the AWS SDK for Android (which seems very similar to the Java SDK, but is nonetheless distinct)
I am using the TransferManager class to perform my upload. Apparently, this is a high-level class that wraps the lower-level AmazonS3Client ... and this lower-level class should expose the error reporting I need, but I am still investigating the exact tradeoffs involved between TransferManager and AmazonS3Client. As far as I can tell, there is no way to get progress information via the (synchronous) AmazonS3Client.putObjectRequest which would be a blocker for me...
UPDATE #2:
My sincere thanks to Jason (of the AWS SDK team) for stopping by and helping me out here. The important information is, indeed, available as properties on an AmazonS3Exception if you use certain methods. The docs had originally confused me and I thought that a manual Thread.sleep() loop was required to poll status (and thus I could not leverage waitForCompletion or waitForException), but if you use ProgressListener on PutObjectRequest you can get full progress callbacks and the error-fidelity of AmazonS3Exception.
these two methods should help you out:
Transfer.waitForCompletion()
Transfer.waitForException()
If you detect that your transfer has failed based on a transfer progress event, you can simply call Transfer.waitForException() to be returned the exception that occurred. That exception will be an AmazonServiceException in this case, with all of the info that you need to see that the real problem was a clock skew issue.
Alternatively, the Transfer.waitForCompletion() method will unwrap the original exception from an ExecutionException and directly throw the original exception, just as if it'd all been happening on one thread. This might be a more convenient approach if you want to use a catch blocks to catch different types of errors cleanly and elegantly.
I disagree that the "catch Exception" block is "brutally broad". The point of that code is to catch any error that happens, mark the transfer as failed and rethrow the error so that the application code can know about it. If it were less broad, then that's exactly the case where exceptions could sneak through and transfer progress wouldn't be updated correctly and would be out of sync with reality.
Give those two methods and shot and let us know if that helps!
Well, I have debugged Amazon's SDK and I'm sorry to say that this information is being swallowed internally. Perhaps I will try to submit a patch.
Details: an AmazonS3Exception is being thrown internally which does in fact accurately report this exact error scenario, but a brutally broad try catch ( Exception e ) consumes it and washes away the specificity.
Here is the guilty try-catch:
https://github.com/aws/aws-sdk-java/blob/master/src/main/java/com/amazonaws/services/s3/transfer/internal/UploadMonitor.java#L145
Here is a screenshot showing that an AmazonS3Exception is correctly thrown with the right info...
I've refactored my application to use a ContentProvider and all the CursorLoader framework but since I've done it, all my test failed because of database error like
java.lang.IllegalStateException: Cannot perform this operation because the connection pool has been closed.
but these occure only in robotium test mode. When I test manually the app it seems to work.
2 days that I'm trying to makes my tests working…
The database management code is available here :
http://code.google.com/p/radis/source/browse/#hg%2Fsrc%2Ffr%2Fgeobert%2Fradis%2Fdb
My test code is available here :
http://code.google.com/p/radis/source/browse/?repo=robotium#hg%2Fsrc%2Ffr%2Fgeobert%2Fradis%2Frobotium
Thanks for any help, this is driving me nuts…