Closed GoogleCodeExporter closed 9 years ago
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?
Original comment by renasr...@gmail.com
on 18 Jul 2010 at 7:22
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.
Original comment by ezelspin...@gmail.com
on 22 Jul 2010 at 7:48
For instance, now I see (but within Junit, so ok):
java.lang.NullPointerException
at
com.jayway.android.robotium.solo.ViewFetcher.getCurrentScrollViews(ViewFetcher.j
ava: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.test
UpdateRenameCollection(ManageCollectionUseCaseTest.java:227)
at
net.lp.collectionista.test.usecases.collections.ManageCollectionUseCaseTest.test
UpdateRenameCollection(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(ActivityInstrumentationTes
tCase2.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:52
0)
at
android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1447)
Original comment by ezelspin...@gmail.com
on 22 Jul 2010 at 8:08
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.
Original comment by renasr...@gmail.com
on 22 Jul 2010 at 9:07
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?
Original comment by ezelspin...@gmail.com
on 25 Jul 2010 at 11:06
Yes this problem will be fixed in the next release. I know exactly why it
happens, thanks for submitting this issue.
Original comment by renasr...@gmail.com
on 25 Jul 2010 at 6:45
Original comment by renasr...@gmail.com
on 12 Aug 2010 at 4:40
This issue has been fixed.
Original comment by renasr...@gmail.com
on 24 Aug 2010 at 4:53
Original issue reported on code.google.com by
ezelspin...@gmail.com
on 17 Jul 2010 at 3:18