Hiii i am testing a test method in which i want after a pressing a button my activity should alive so that i can see next test cases in that activity,but unfortunately my activity get killed after running the test case .is there any way to keep the activity alive.if there code line please let me inform.
I cannot be sure without seeing your code, but i am guessing either in the testcase, or the setup() and tearDown() methods you are going to have to been calling a method such as finishOpenedActivities() which closes all the activities you have open. removing this line will keep the activity open.
Having said that it is typically best practice to have your test cases start from a clean state because having test cases that rely on ordering means that if one fails all the others fail even if that functionality does work plus you have to do slightly hacky things in order to get them to all run in the order you want.
I dug into the source code a bit and found that the tearDown() method, as implemented in ActivityInstrumentationTestCase2, will make a call to finish() on your current activity. So even if you don't explicitly finish() you Activity in your implementation of this method, it will be done when calling super. However, per the source code documentation: removing the call to super in tearDown() can cause a memory leak if you have a non-static inner class, and, perhaps more importantly for your case, the running Activity seems to still be killed once the test is completed. Even if you have an empty implementation of tearDown(), it seems as though the Activity Under Test gets finished at the end of the run. As of right now, I don't know of a way to avoid this.
As an alternative based on your comment for #Paul Harris's answer, Robotium has many methods that allow you to wait for something to happen. You may want to look into waitForText() or waitForView(), which can take a timeout as a argument, to have Robotium pause while your button click is performing some action. Hope this helps!
Related
Writing a kotlin social media app. I want to do 3 things within the logout sequence:
logoutbutton.setOnClickListener() {
//1. db.logout()
//2. finish()
//3. go to login screen
}
Does the order of events matter here? This is the order I am going with right now, but I don't know where the best place to put finish() would be.
Call finish when you want the current activity to popped off the activity stack. You typically do that when the user has indicated they no longer want to interact with it. Other than that, the order of these things don't really matter.
A trap that has caught me a few times is that finish() is actually asynchronous, so can give the illusion that instructions following it are "safe"... until they take a little longer and the activity gets torn down before they complete.
That can make for very difficult bugs to find.
I suggest for safety, call finish last.
I'm assuming db.logout may take some time to complete and/or may have to run on a background thread so some caution may be needed there. Fortunately Coroutines can help a lot .
In my instrumentation/unit test, I'd like to verify that an Activity's method is called in onCreate (when app is launched AND while it is already open) and onNewIntent.
I've tried ActivityTestRule, but I ran into two problems:
I have to invoke onNewIntent on the ui thread, because it modifies the view. So I'm forced to do something like Thread.sleep to wait for the task to finish
It's impossible to spy the activity in the rule without hacking the library
I've also looked into Robolectric, but it seems like it has a reputation for being flaky and slow.
Any suggestions for possible approaches with Espresso or Mockito or a different testing framework?
I perform some app global initialization in my Application's OnCreate (a subclass of Application). In some rare occasions this initialization fails. When that happens I used to show an activity with a failure message, but apparently this was a bad idea since this function also being called before my background Service is started, which then launches this "failure" activity out of nowhere.
My current solution is to mark with some flag that the initialization failed, and check it in every activity (or Service) that the app might start with. This solution is also bad, because it requires me to remember to check it in every new component I add (that can be launched).
Does someone have a better idea?
If Application initialization fails, you're screwed. Throw an exception and give up.
As corollaries:
Keep the Application init as thin as possible - do as little as possible.
Avoid doing anything that can fail.
Postpone operations that can fail to a point where you have more options for recovery, such as an Activity's lifecycle.
If you need help with a specific failure, please include it in your question.
I am having some issues with my Robotium tests. I have 3 test classes that each have about 2 to 3 methods. They all test different activities in the Android Life Cycle. The problem I am finding is that when test A presses a button in A the intent is called for the next activity the test passes and then finishes. Then test B tries to start an activity. I noticed then that the Activity from test A is still alive. I tried using this to help the problem. The idea would be that the device would wait till the activity was idle then I will end any inactive activities. Then I would end any ones that were open and left.
getInstrumentation().waitForIdleSync();
solo.finishInactiveActivities();
solo.finishOpenedActivities();
I am not sure if this is 100% the best way of taking care of this problem. I have noticed that it works 80% of the time but I am still getting some leaks.
I solved the problem by using the solo.goBack(); function call. This will kill all of the open activities so that there is no leak of activities during your testing. As well I used the code I had placed above as double cover. After repeating these tests on numerous devices and scenarios it seems to pass.
My instrumentation is launching an activity to instrument it, but I can't seem to find an elegant way to tell when it's safe to start sending it my MotionEvent's. At the moment, I'm continually sending it MotionEvent's, and catching the SecurityException's that get thrown when the wrong application receives them.
The problem with this approach is that when the first event gets through, the application responds to it, so this method is not without side effects...
I was thinking of trying to do something with UID's, but I don't know where to look for that.
You might be able to leverage the standard Android lifecycle methods that get called on your Activity. You could set an 'infront' flag in onResume(), and clear it in onPause(). Then your instrumentation test just checks that flag to know when it's safe to send MotionEvents.
If you don't want to pollute your app by putting in code specifically for test purposes, create a subclass, override onResume/onPause, set the flags, and call super.