i have a main activity and when tap on the button in the main activity it moves to the another activity than runs on another process .. is there a chance to track/get that activity using robotium /by means of other codes to integrate with robotium
Unfortunately no. Robotium builds upon Android's instrumentation objects which are limited to work only within the process of the instrumentation for the given target Activity (as you define a target process in the test-manifest file).
I don't know how it behaves in cases where the target process has a defined shared user id, though...
Related
Android Espresso testing app flow
I use Espresso to test a lot of activities and transitions between them. I want to write different test for those activities and link the Activity Intents to the corresponding test cases.
1 . Activity A (testActivityA runs) 2. ActivityA launches ActivityB (testActivity B) should be called
is it possible to do this with espresso or any other test framework?
You should test each activity independently of the others. If you need them to react to incoming intents, you can do that using Espresso Intents.
I need to test a use case where the application starts from a clean state - i.e. the process has not been running before the test starts. From what I see from logcat, all instrumentation tests run under one single process instance/session, so the outcome of the test in my case depends on whether or not it runs as #1 or not. It should not be this way - as we all know, unit tests (or instrumentation tests) should be autonomous.
Is there any way with the standard Android instrumentation test tools and functions I can force the TestRunner to restart the process before a given test? If not, are there hacks or third-party libraries that can help me achieve that? Or is there any way I can specifically say that test X must be run first (worst option but still)?
In specific, my test relates to the launching of activities through intents, and the intent flags (e.g. FLAG_ACTIVITY_CLEAR_TOP) in addition to the Activity launch mode (e.g. singleTop) and the state of the process, very much dictates the outcome of the test.
Assuming you are running with Espresso, there is not a clean way to pull this off. This is because Espresso runs in the same process as the application and thus killing the app will kill Espresso.
The question is, do you need all the logic you want to execute in your Application or could it be ported to your Activity.onCreate()? With Espresso restarting an Activity is doable. If there is a need to restart the application because of global/singletons, removing these may be necessary. If this cannot be done you can look at other test automation frameworks like Appium which has some support for this.
A common situation I face is that I wish to test a custom View visibly on screen while it is being developed as part of a large application. I realise that unit testing exists, particularly using ActivityUnitTestCase, but as far as I understand these frameworks don't actually attach the components visibly on screen.
At present, the way I tend to do this is to just place the component wherever it will actually be used within the application. This often means needing to wait some time for the application to start or to navigate through parts of the application before it is visible, which can become cumbersome.
The better way I've found is to create an Activity within the application that exists purely for test purposes (e.g. to simply display a custom View I'm developing), which is launched to display the custom View (or whatever) that I am working on. To do this, the only intent filter I've assigned to that Activity in the manifest is android.intent.action.MAIN, and not android.intent.category.LAUNCHER. Then, I can simply create a Run/Debug Configuration in Android Studio to launch that Activity directly. This, as far as I believe, effectively allows me to have Activity classes which may only be launched by me from the IDE.
My questions are:
Does omitting android.intent.category.LAUNCHER guarantee that users of the application won't be able to launch that Activity by any means nor be aware of its existence? Is this a safe to have Activity classes for development only?
Is there a workflow or test framework of any kind I could use to improve on how I am doing this?
I realise that unit testing exists, particularly using ActivityUnitTestCase, but as far as I understand these frameworks don't actually attach the components visibly on screen.
Well, ActivityInstrumentationTestCase2 does, as does the new ActivityTestRule. I don't recall playing with ActivityUnitTestCase.
Does omitting android.intent.category.LAUNCHER guarantee that users of the application won't be able to launch that Activity by any means nor be aware of its existence?
No. It won't be easy for them to start it, but it is exported and has an <intent-filter>, so somebody could find a way.
Is this a safe to have Activity classes for development only?
I would put them in your debug sourceset, assuming that you are using Android Studio. Here is a sample project that has a production launcher activity in main and a diagnostic activity in debug. In a release build, the diagnostic activity does not even ship.
Why don't declared some value like
public static boolean IS_DEBUG = true;
then in any part you want to show it, just put in condition like
if (IS_DEBUG) {
your_develop_view.setVisibility(View.VISIBLE);
//...
}
else {
your_develop_view.setVisibility(View.GONE);
}
after you finish develop. before you publish, just change
IS_DEBUG = false;
Instead of defining your own IS_DEBUG, just use BuildConfig.DEBUG
In my test class, i have multiple test cases written. Now when I run the test project, after each test case the app is getting stopped and started again. In teardown I am calling solo.finishOpenedActivities().
I want to run all test cases without closing the activities.
I tried to remove solo.finishOpenedActivities from the tearDown method. In that case the next testCases are not getting executed and the test hangs after the first one.
So what is the proper way to have multiple test cases and not close the activities and continue running all the tests?
If the functionalities between your test cases are dependent on each other, then instead of writing them in separate testcases, write different functions related to different functionality and call then in same testcase according to their order of execution.
Because, after completion of each testcase, robotium will definitely close the activity and start a new activity for the other testcase.
I'm a bit confused about the difference between a task and a process in Android.
If I understand correctly a task is just a stack of activities. From what I read so far I think a task could look like this:
| Activity A running in Process P1 |
| Activity B running in Process P2 |
| Activity C running in Process P3 |
So basically activities from different processes can be contained in the same stack. Am I correct?
Another question: What is the real meaning of "application context"? The process or the task?
And final question: The application class (which is basically a singleton) represents the process or the task?
Everything I've ever learned about it, I've learned on this page.
Edit: I also just stumbled upon Activity and Task Design Guidelines. It looks to cover the exact topic you asked about. I learned a lot :)
So basically activities from different
processes can be contained in the same
stack. Am I correct?
Based on my understanding, you are correct. My grasp is that Processes are the units of actual execution while Tasks are about association to get things done. As an example from the aforementioned page, if you create an intent that opens a webpage, the Activity that it creates is created on the web browsers process but is associated with your applications Task. A task, therefore, becomes a virtual stack of Activities running on different processes depending on the application that provided the Activity.
Another question: What is the real
meaning of "application context"? The
process or the task?
This is a good question. Based on reading the page above, my understanding is that an Applications context is associated with the process. I'm basing that on the interpretation of this line from that page, but there may be other info:
Normally, a new instance of an
activity is launched into the process
of the application that defined it, so
all instances of the activity run in
the same process
And final question: The application
class (which is basically a singleton)
represents the process or the task?
With the same interpretation as above, my guess as to why an Application object represents a Singleton is because all of your applications activities get run on a single process and that process is tied to the Application. I don't know that this is a design point, but it appears to be, at the least, a consequence of the current design.
Edit: There are some caveats to this. It appears that your application can be spread across multiple processes so, my guess is that the Application Object and context act as a mechanism for tethering all the processes together. I'm pretty sure your mental model already allowed for this, assuming the processes were from different applications, so its only a small difference to allow it inside a single process.
The manifest element has the attribute android:process with the description as follows:
The name of the
process in which the activity should
run. Normally, all components of an
application run in the default process
created for the application. It has
the same name as the application
package. The element's
process attribute can set a different
default for all components. But each
component can override the default,
allowing you to spread your
application across multiple processes.
If the name assigned to this attribute
begins with a colon (':'), a new
process, private to the application,
is created when it's needed and the
activity runs in that process. If the
process name begins with a lowercase
character, the activity will run in a
global process of that name, provided
that it has permission to do so. This
allows components in different
applications to share a process,
reducing resource usage.
Process:
When an application component starts and the application does not have any other components running, the Android system starts a new Linux process for the application with a single thread of execution. By default, all components of the same application run in the same process and thread (called the "main" thread).Every application runs in its own process and all components of the application run in that process, by default.
for detail process: http://developer.android.com/guide/components/processes-and-threads.html
Tasks:
A task is a collection of activities that users interact with when performing a certain job. The activities are arranged in a stack (the "back stack"), in the order in which each activity is opened.
An activity can even start activities that exist in other applications on the device. For example, if your application wants to send an email, you can define an intent to perform a "send" action and include some data, such as an email address and a message. An activity from another application that declares itself to handle this kind of intent then opens. In this case, the intent is to send an email, so an email application's "compose" activity starts (if multiple activities support the same intent, then the system lets the user select which one to use). When the email is sent, your activity resumes and it seems as if the email activity was part of your application. Even though the activities may be from different applications, Android maintains this seamless user experience by keeping both activities in the same task.
for detail task-http://developer.android.com/guide/components/tasks-and-back-stack.html
An important note from Android Developer :
A common misunderstanding about Android multitasking is the difference
between a process and an application. In Android these are not tightly
coupled entities: applications may seem present to the user without an
actual process currently running the app; multiple applications may
share processes, or one application may make use of multiple processes
depending on its needs; the process(es) of an application may be kept
around by Android even when that application is not actively doing
something.