Closed GoogleCodeExporter closed 9 years ago
GoogleCodeExporter
commented
9 years ago Thanks for reporting this. Are you running the test cases in different threads?
Would it be possible for you to share your test project?Original comment by renasr...@gmail.com on 19 Feb 2015 at 3:14
GoogleCodeExporter
commented
9 years ago Here is a code sample of one place this has occurred, the code have been
trimmed for brevity.
public class EmailActivity_Test extends
ActivityInstrumentationTestCase2<EmailActivity> {
private Solo solo;
@Inject
Api api;
public EmailActivity_Test() {
super(EmailActivity.class);
}
@Override
protected void setUp() throws Exception {
super.setUp();
Injector.add(
new AppModule(getInstrumentation().getTargetContext()),
new FormatterModule(),
new EmailTestModule());
Injector.inject(this);
User.setCurrentUser(TestData.buildUserTutor());
Token.setCurrentToken(TestData.buildToken());
}
@Override
protected void tearDown() throws Exception {
if (solo != null) {
solo.finishOpenedActivities();
}
super.tearDown();
}
public void testClickingForwardGoesToCompose() throws Throwable {
Email email = TestData.buildEmailTestData();
List<EmailUser> emailUsers = TestData.buildEmailUserTestData();
Intent intent = new Intent(Constants.ACTIONS.EMAIL);
intent.putExtra(Constants.EXTRAS.EMAIL_ID, email.getId());
setActivityIntent(intent);
Mockito.doReturn(buildEmailResponse(email, emailUsers)).when(api).getEmail(Mockito.anyLong(), Mockito.eq(email.getId()));
solo = new Solo(getInstrumentation(), getActivity());
Instrumentation.ActivityMonitor monitor = getInstrumentation().addMonitor(new IntentFilter(Constants.ACTIONS.FORWARD_EMAIL), null, true);
solo.clickOnMenuItem("Forward");
Activity activity = monitor.waitForActivityWithTimeout(5000);
assertTrue(activity instanceof ComposeEmailActivity);
}
}
Original comment by Jonathan...@gmail.com on 19 Feb 2015 at 5:10
GoogleCodeExporter
commented
9 years ago Interesting how you are using multiple frameworks in one test case. What
happens if you remove:
Instrumentation.ActivityMonitor monitor = getInstrumentation().addMonitor(new
IntentFilter(Constants.ACTIONS.FORWARD_EMAIL), null, true);
Activity activity = monitor.waitForActivityWithTimeout(5000);
assertTrue(activity instanceof ComposeEmailActivity);
And instead use the Activity API:s in Robotium. E.g.
solo.assertCurrentActivity(), solo.getCurrentActivity etc?
Also please use the latest Robotium version, 5.3.1. Original comment by renasr...@gmail.com on 19 Feb 2015 at 5:14
GoogleCodeExporter
commented
9 years ago The problem with using assertCurrentActivity is the delay between clicking a
view and when the next activity is actually on screen. I had it implemented the
way you describe and would frequently see the test fail because the activity
assert was triggering too fast. And using waitIdleSyncs or Thread.sleep as
intermittently produces similar results. The only way to solve those issues has
been to use an ActivityMonitor to wait for the activity to load. The thing
though is that the test itself actually is succeeding its when trying to close
the activities in the tearDown method that is having an issue.Original comment by Jonathan...@gmail.com on 19 Feb 2015 at 5:35
GoogleCodeExporter
commented
9 years ago Thats strange. The activity assert should wait for the specified Activity
for 10 seconds before failing.
Your'e getting the ConcurrentModificationException as
solo.finishOpenedActivities() is triggered twice at the same time. The list
holding the weak activity references can't handle that. You could do a log
printout in tearDown() just to see which tests call the tearDown at the
same time.Original comment by renasr...@gmail.com on 19 Feb 2015 at 5:43
GoogleCodeExporter
commented
9 years ago It could also be that the teardown is run at the same time a new Activity
is opened. You could end the test first when the new activity is opened.
Basically use a solo.waitForActivity in the end.Original comment by renasr...@gmail.com on 19 Feb 2015 at 5:47
GoogleCodeExporter
commented
9 years ago My apologies, I have not yet tried solo.assertCurrentActivty(). I wasn't aware
that it would wait a few seconds for the specified activity. I am attempting to
upgrade to version 5.3.1 and will swap in solo.assertCurrentActivty() and see
if the failure pops up anymore today.Original comment by Jonathan...@gmail.com on 19 Feb 2015 at 5:50
GoogleCodeExporter
commented
9 years ago Swapping out those ActivityMonitor for solo.assertCurrentActivty() seems to
have done the trick. I did briefly try updating to 5.3.1 and had to roll back
because it was causing others tests to start breaking that involved click
things in a PopupWindow. Once I get a chance I will try upgrading again to see
what the problem really is with that. Thanks for your assistance.Original comment by Jonathan...@gmail.com on 20 Feb 2015 at 4:56
GoogleCodeExporter
commented
9 years ago Original comment by renasr...@gmail.com on 25 Feb 2015 at 5:25
Original issue reported on code.google.com by
Jonathan...@gmail.comon 19 Feb 2015 at 2:21