Testing that an OptionsMenu item is disabled

[GoogleCodeExporter]

As far as I can tell, there is presently no way to determine if an OptionsMenu 
item is enabled or disabled.  I thought I'd as a workaround try to use 
clickOnMenuItem to ensure that the application ignored the "press" of a 
disabled button, but the test fails when the item is (correctly) disabled.  

junit.framework.AssertionFailedError: The text: Disabled Button is not found!
at com.jayway.android.robotium.solo.Clicker.clickOnText(Clicker.java:279)
at com.jayway.android.robotium.solo.Clicker.clickOnMenuItem(Clicker.java:200)
...

If you have any workaround ideas, I'm open to them.  Otherwise, please add this 
feature when you can.  Thanks so much!

Original issue reported on code.google.com by glenview...@gmail.com on 30 Jan 2012 at 7:52

[GoogleCodeExporter]

I tried to work around this way, but it failed.  I suspect the sendKey failed 
because I'm using an emulator with a disabled keyboard.

solo.sendKey(KeyEvent.KEYCODE_MENU)
assertFalse(solo.searchText("Disabled Button"))
solo.goBack()

Instead I used this technique, which only verifies that the item was disabled 
because if I called goBack when the item was enabled, it would end up leaving 
the Activity:

solo.pressMenuItem(0)
solo.goBack()

Original comment by glenview...@gmail.com on 30 Jan 2012 at 8:09

[GoogleCodeExporter]

What if you use solo.getButton("disabled button).isEnabled()?

Original comment by renasr...@gmail.com on 31 Jan 2012 at 8:56

[GoogleCodeExporter]

Remember I'm talking about an OptionsMenu item, not a Button.  Trying your 
suggestion resulted in the following error:

junit.framework.AssertionFailedError: No Button with text Disabled Item is 
found!
at com.jayway.android.robotium.solo.Getter.getView(Getter.java:71)
at com.jayway.android.robotium.solo.Solo.getButton(Solo.java:1377)

I tried both:

solo.pressMenuItem(0) // to ensure the menu was activated
assertFalse(solo.getButton("Disabled Item").isEnabled()) 
solo.goBack()

and just: 
assertFalse(solo.getButton("Disabled Item").isEnabled()) 

Both versions produced the error.

Original comment by glenview...@gmail.com on 31 Jan 2012 at 2:15

[GoogleCodeExporter]

Sorry about that. I mean solo.getText("disabled item").isEnabled()

Please try that and tell me how it goes. 

Original comment by renasr...@gmail.com on 31 Jan 2012 at 2:43

[GoogleCodeExporter]

The below code:

solo.pressMenuItem(0) // to ensure the menu was activated
assertFalse(solo.getText("Disabled Item").isEnabled()) 
solo.goBack()

resulted in the following error:

junit.framework.AssertionFailedError: No TextView with text Disabled Item is 
found!
at com.jayway.android.robotium.solo.Getter.getView(Getter.java:71)
at com.jayway.android.robotium.solo.Solo.getText(Solo.java:1352)

Eliminating the solo.pressMenuItem(0) also produces the same error.

Original comment by glenview...@gmail.com on 31 Jan 2012 at 2:57

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

And you can see that exact text view in the menu (disabled but still there)? 
And the menu is indeed open when getText is executed? 

Original comment by renasr...@gmail.com on 31 Jan 2012 at 3:06

[GoogleCodeExporter]

Yes, the text view is there in the menu, and in the case where I call 
solo.pressMenuItem(0), the menu is showing.  The pressMenuItem call has the 
effect of showing and keeping open the options menu because item 0 is the 
disabled one, so the menu does not disappear.  Hence the need for the 
solo.goBack().  

Please also note that this is the initial options menu with icons that's 
showing, not the extended one you get that is just text when you click the 
"more" options menu item.

Original comment by glenview...@gmail.com on 31 Jan 2012 at 3:11

[GoogleCodeExporter]

Incidentally, do you have a test case that shows that this use case is covered?

Original comment by glenview...@gmail.com on 31 Jan 2012 at 3:12

[GoogleCodeExporter]

Ok. 2 more things:

1. What happens if you do solo.getText(0).isEnabled()?

2. Does searchText() find it (return true)?

Original comment by renasr...@gmail.com on 31 Jan 2012 at 3:45

[GoogleCodeExporter]

Both worked.  I needed to add a solo.waitForText("Disabled Item") between the 
solo.pressMenuItem(0) and the solo.searchText()/getText(0) because 
getText(String or int) times out before the menu is shown.  

So the following works:

solo.pressMenuItem(0) 
assertTrue(solo.waitForText("Disabled item"))
assertFalse(solo.getText(0).isEnabled())
solo.goBack()

By the way, I second the request in Issue 77 to be able to globally configure 
timeout values for getText etc., as I seem to encounter similar issues 
sporadically.

I would be prefer if there were a solo.getMenuItem(String) and 
solo.getMenuItem(int) that would do all of this for you.  It would open the 
menu, get the item view, then close the menu.

Original comment by glenview...@gmail.com on 31 Jan 2012 at 5:04

[GoogleCodeExporter]

If you remove waitForText() does it fail even though you see that the menu is 
opened and items are shown? There is a 10 second timeout for getText(). 

Original comment by renasr...@gmail.com on 31 Jan 2012 at 7:19

[GoogleCodeExporter]

You know--I'm not sure what's going on.  Even the code below that I previously 
wrote works, is actually intermittent.  Same for the waitForText().  My 
application code is definitely functioning correctly, but the test code is not. 
 I'm using robotium 3.1.

solo.pressMenuItem(0) 
assertTrue(solo.waitForText("Disabled item"))
assertFalse(solo.getText(0).isEnabled())
solo.goBack()

Original comment by glenview...@gmail.com on 31 Jan 2012 at 7:55

[GoogleCodeExporter]

Incidentally, there are other searchText() calls in my suite that I'm seeing 
fail intermittently.

Original comment by glenview...@gmail.com on 31 Jan 2012 at 7:57

[GoogleCodeExporter]

Would it be possible for you to send me your application and test project? 
Because this is an issue that Im very eager to analyze closer. 

Original comment by renas.r...@jayway.com on 31 Jan 2012 at 7:59

[GoogleCodeExporter]

I appreciate that very much, but I'm really not comfortable sharing it.  
Besides it's large and has lots of external dependencies and would be quite a 
pain to configure.  Do you have a test in the robotium test suite that 
addresses hidden menu items?  I could show you how to hide menu items if you 
don't already have such a test.

Original comment by glenview...@gmail.com on 31 Jan 2012 at 8:08

[GoogleCodeExporter]

The issue is not with it being disabled. That does not matter when it comes to 
getText(), it will not filter any views based on if they are enabled or not. 
The issue is however that getText() and searchText() (sometimes) do not get 
access to the right views. This is the issue that I want to analyze. 

Original comment by renasr...@gmail.com on 31 Jan 2012 at 8:53

[GoogleCodeExporter]

Original comment by renasr...@gmail.com on 31 Jan 2012 at 9:42

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by renasr...@gmail.com on 10 Apr 2012 at 6:45

• Changed state: WontFix

[GoogleCodeExporter]

I suspect that what was happening here is that OP's UI element may not have 
directly inherited from a View.

For instance, I'm testing a Preference inside of a PreferenceScreen, which may 
take a second or so to become enabled on older devices (e.g., Android 2.2). 
Preference does not inherit directly from View (see Android docs), so some 
additional steps are required to get a handle on the view (getRootAdapter).

Original comment by liuch...@gmail.com on 12 Jun 2013 at 12:56