ArrayIndexOutOfBoundsException while looking for a view with searchText about robotium HOT 8 CLOSED

From [email protected] on July 18, 2010 00:22:30

Thanks for the issue.

Can you please send me some code that exhibits this problem or some more information? How often does this happen to you, is it under certain conditions?

from robotium.

From [email protected] on July 22, 2010 00:48:32

I think this only happens if you specify a solo.goBack() too many so that you actually exit your app and then try to searchText() wrongfully. I'll try and see if I can create some minimal sample code that exhibits this. Downloading my project and its dependencies might be a bit much. Though you can find it at https://code.launchpad.net/~pjv/collectionista/tests . Should be revision 14 (or 15) with some small changes (try inserting goBack()'s). You will also need the other trunks and dependencies.

I certainly don't always see this as a real exception. I think when this happens still INSIDE the app, you just get a comparable stacktrace, but WITHIN junit, as it should.

from robotium.

From [email protected] on July 22, 2010 01:08:28

For instance, now I see (but within Junit, so ok):

java.lang.NullPointerException
at com.jayway.android.robotium.solo.ViewFetcher.getCurrentScrollViews(ViewFetcher.java:242)
at com.jayway.android.robotium.solo.Scroller.scroll(Scroller.java:149)
at com.jayway.android.robotium.solo.Scroller.scrollDown(Scroller.java:104)
at com.jayway.android.robotium.solo.Searcher.searchForText(Searcher.java:354)
at com.jayway.android.robotium.solo.Searcher.searchText(Searcher.java:312)
at com.jayway.android.robotium.solo.Searcher.searchText(Searcher.java:294)
at com.jayway.android.robotium.solo.Searcher.searchText(Searcher.java:278)
at com.jayway.android.robotium.solo.Solo.searchText(Solo.java:273)
at net.lp.collectionista.test.usecases.collections.ManageCollectionUseCaseTest.testUpdateRenameCollection(ManageCollectionUseCaseTest.java:227)
at net.lp.collectionista.test.usecases.collections.ManageCollectionUseCaseTest.testUpdateRenameCollection(ManageCollectionUseCaseTest.java:207)
at java.lang.reflect.Method.invokeNative(Native Method)
at android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:204)
at android.test.InstrumentationTestCase.runTest(InstrumentationTestCase.java:194)
at android.test.ActivityInstrumentationTestCase2.runTest(ActivityInstrumentationTestCase2.java:186)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169)
at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154)
at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:520)
at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1447)

from robotium.

From [email protected] on July 22, 2010 02:07:41

So the last NullPointerException you have posted happened while still being in the application? A special scenario to make it happen?

I will make a change in the next release so that this problem is avoided. Thanks for pointing it out.

Status: Accepted

from robotium.

From [email protected] on July 25, 2010 04:06:25

Exactly, the stacktrace from comment #3 is benign. It's the thing you want to see in jUnit if your program or test code is wrong. The stacktrace from the original post is not, it was retrieved through logcat.

I've been trying to get back the code that exhibited the problem, both in my fullproject, as in a small sample project, but have been unsuccessful. However at the time I could reproduce this 100% with that code. Sorry, I should have made a commit at that moment. Can you do anything useful with the stack trace by itself and the context of my code?

from robotium.

From [email protected] on July 25, 2010 11:45:49

Yes this problem will be fixed in the next release. I know exactly why it happens, thanks for submitting this issue.

from robotium.

From [email protected] on August 12, 2010 09:40:39

Owner: renasreda

from robotium.

From [email protected] on August 23, 2010 21:53:50

This issue has been fixed.

Status: Verified

from robotium.