[Macrobenchmarks] - It is wrong to assume device.findObject() will always return the object. #711
-
On my personal project as well as the nowinandroid project, I have experienced sometimes the baseline generator/macrobenchmark fails to find this object sometimes.
Do we expect the test to fail and crash the app(stopping after the last iteration) or skip the process when the object is not found and continue with the tests. Why not use this?
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
IMO, we should never silently ignore this kind of null return value. This is definitely a bad testing practice and will hide potential bugs. Unfortunately,
This means that tests will fail with a semantically "wrong" device.findObject(By.text("foo")).click()
A better solution would be to create this kind of extension: fun UiDevice.getObject(selector: BySelector): UiObject2 =
findObject(selector) ?: error("Object not found for: $selector") And using it like this: device.getObject(By.text("foo")).click() will produce this error message:
In this project, we already have this kind of extension that behaves similarly |
Beta Was this translation helpful? Give feedback.
IMO, we should never silently ignore this kind of null return value. This is definitely a bad testing practice and will hide potential bugs.
Unless there is a very good reason to handle it, for instance if we want to check 2 potential different code paths, you probably never should do that.
Unfortunately,
UiAutomator
has been designed in Java, and never received proper nullability annotations.Although the Javadoc explicitly mention the potential null return value:
This means that tests will fail with a semantically "wrong"
NullPointerException
on the next operation:device.findObject(By.t…