Robotium's all-purpose ActivityMonitor breaks non-Robotium tests about robotium HOT 7 CLOSED

From [email protected] on December 17, 2010 10:35:28

This is the only way for Robotium to catch all new activities. Otherwise the user has to define which activity they want to catch and then it would loose its function. It is unfortunate that it is not working for you but this is according to design. It has to catch all new activities.

Status: WontFix

from robotium.

From [email protected] on December 19, 2010 01:36:30

I think the problem may not be the fact that an ActivityMonitor with a null-handler is added, but that it's never removed again! You should always pair calls to addMonitor/removeMonitor. Robotium should register the monitor in setUp, and remove it in tearDown.

I still think this is an issue that should be fixed (and from what I can tell, can be fixed), since it would greatly help making Robotium less intrusive into the standard testing environment.

from robotium.

From [email protected] on January 03, 2011 01:18:20

Can somebody suggest any workarounds? This kind of makes it impossible to use robotium in majority of my tests. For example, my activity opens a file with PDF viewer and I really do not want to deal with PDF app in my tests.

from robotium.

From [email protected] on February 12, 2011 09:08:51

FYI: I came across this problem independently and fixed it a few weeks ago, so it should be in the next release. cc8bb82

from robotium.

From [email protected] on March 27, 2011 07:46:54

has this been fixed? I'd like to remove the callout to not use custom Activity Monitors with Robotium from my book :-)

from robotium.

From [email protected] on March 28, 2011 00:58:08

Hey Matthias,

The catch-all ActivityMonitor is now removed during finalize(), as my commit in comment 4 shows. This was included in release 2.2 :)

from robotium.

From [email protected] on March 28, 2011 01:00:53

awesome, thanks!

(@renas: can you resolve this as fixed?)

from robotium.