search

JGeovani / robotium

Automatically exported from code.google.com/p/robotium
1 stars 0 forks source link

Add option to disable catch-all ActivityMonitor #103

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
As mentioned in issue 47, there is a catch-all ActivityMonitor which is set up 
when a Solo instance is constructed.

This is required to wait for a particular Activity, or to go back, etc.

However, there are cases where I don't want to use this functionality, but *do* 
want to use an ActivityMonitor.  e.g. I want to open a Dialog, press a button 
which launches an Intent to an external process, then verify that the Intent 
was sent -- but I need that Intent to be blocked.  For this I would need to 
apply a specific ActivityMonitor.

Do you think it would be possible to add a Solo constructor which specifies 
that the ActivityMonitor setup behaviour should be disabled / would you accept 
a patch which does this?

Or have I missed a way that this test can be run currently? :)

Original issue reported on code.google.com by chris@orr.me.uk on 18 Apr 2011 at 11:24

GoogleCodeExporter commented 9 years ago 
The problem with adding and using a option like this is that 
getCurrentActivity() and all the methods that are using the activitymonitor 
would stop to function. Would it work for you that we add a method that returns 
the ActivityMonitor used in Robotium? In that case you could do a 
inst.removeMonitor(activityMonitor); in your test case and add a new 
ActivityMonitor that better suits your needs?

Original comment by renasr...@gmail.com on 18 Apr 2011 at 12:22

GoogleCodeExporter commented 9 years ago 
Yes, that sounds like an easier solution to implement, and lets you be more 
precise about when to disable/replace the ActivityMonitor.

Good idea :)

Original comment by chris@orr.me.uk on 18 Apr 2011 at 12:53

GoogleCodeExporter commented 9 years ago 
Great. That will be included into the next release :)

Original comment by renasr...@gmail.com on 18 Apr 2011 at 1:00

GoogleCodeExporter commented 9 years ago

Original comment by renasr...@gmail.com on 18 Apr 2011 at 6:20

GoogleCodeExporter commented 9 years ago 
This has been included into Robotium 2.3

Original comment by renasr...@gmail.com on 21 Apr 2011 at 5:46

GoogleCodeExporter commented 9 years ago 
Thanks for doing this change. I added something this like in my base TestCase, 
in case it's useful to anyone else:

/**
 * Runs the given action, monitors activity starts for the given FQCN
 * (e.g. {@code MyActivity.class.getName()}. Returns the monitor hit
 * count, typically 1 on success.
 *
 * @param solo The instance of Solo
 * @param activityFQCN The activity FQCN that should be started.
 * @param action The action that should start the activity.
 * @return The hit count of the activity monitor.
 */
int monitorActivityStart(Solo solo, String activityFQCN, Runnable action) {

    // Solo has its own catch-all monitor which we must remove and replace
    // by ours temporarily, then restore it back.
    ActivityMonitor soloMonitor = solo.getActivityMonitor();
    ActivityMonitor myMonitor = new ActivityMonitor(
            PrefsTabUI.class.getName(),
            null, // result
            true); // block
    try {
        getInstrumentation().removeMonitor(soloMonitor);
        getInstrumentation().addMonitor(myMonitor);
        assertEquals(0, myMonitor.getHits());

        action.run();

        getInstrumentation().waitForIdleSync();
        getInstrumentation().waitForMonitorWithTimeout(myMonitor, 1000);
        return myMonitor.getHits();
    } finally {
        getInstrumentation().removeMonitor(myMonitor);
        getInstrumentation().addMonitor(soloMonitor);
    }

}

Original comment by r...@android.com on 21 Nov 2011 at 5:20