I have written code to run tasks on job scheduler. Testing it on real device works fine. But i wanted a way to unit test it so that i can be sure it is covering all conditions like job success/failure/ runs when conditions are met, periodic etc. Please suggest me a way to write unit tests for these scenarios
You can run jobs on-demand via adb, as well as force an immediate timeout of an executing job as though it had reached the end of its timeslice. See the output of
adb shell cmd jobscheduler
for a summary of useful commands.
Related
I had an issue to run my ui test
#Test
fun firstUi() {
onView(withId(R.id.home_profile_tab)).perform(click())
onView(withId(R.id.enter)).perform(click())
onView(withId(R.id.tvCountryCode)).check(matches(withText("+964")))
}
This test run and passed
But the issue is, after running test and reaching to first line, the firs perform(click)) executed after around 90 seconds, and it is almost constant and every time it takes 90 seconds
But after that (90sec) other lines executed and test completed around 4 seconds and passed successfully
Base on android documentation:
Each time your test invokes onView(), Espresso waits to perform the
corresponding UI action or assertion until the following
synchronization conditions are met:
The message queue is empty.
There are no instances of AsyncTask currently executing a task.
All developer-defined idling resources are
idle.
So how and where can I investigate more to detect to root cause of issue???
Or what I'm doing wrong???
With the help of this post I found what was my issue
I live in iran and most of services because on sanctions are banned here
So I looked in Frames, so I found that some AsyncTask are exist for some sdk, that are trying to send request to their server, but because of ban they couldn't
So they keep retrying, maybe after 90sec without a successful request call they give up, and Espresso requirements meet to continue running tests
My Solution was using VPN, so sdk can successfully make request to their servers
I am running android-cts . The commands I run are mentioned below,
cts-tf
run-cts --plan --cts-camera
It is being running for two days . How do I stop the current task and save the existing logs .
Also it is mentioned in documentation ,that the cts logs will be stored in
CTS_ROOT/android-cts/results/start_time.zip
But I dont see a start_time.zip in the location specified .
There are few ways by which you can stop the CTS invocation and result will be generated of your runs,
Unplug the USB Cables from the devices, this will make tradefed to not detect any device and once timeout occurs, it will generate result on testcases and modules it ran.
Kill command, just write the kill in the tradefed, and it will kill and stop the invocation threads for the runs. once that is done, it will generate the result but make sure not to give kill command more than 1 or else it will exit from tradefed without generating the result.
I have a JobService that is properly implemented and works fine in simple cases but I want to ensure the service is properly tested in all conditions.
I'd like to use an Instrumentation test case so that I can test the full flow from the scheduling of the job with getSystemService(JobScheduler.class).schedule(job) to the invocation of onCreate in my JobService and my onStartJob/onStopJob calls.
My JobService launches AsyncTasks sometimes (thereby returning true in onStartJob) and other times it returns false for work that's already done. I have various calls to jobFinished(mJobParameters, needsReschedule) and I'd like to ensure that they work properly as well.
I've been trying to get instrumentation tests working for the past couple days but the best I've been able to come up with is a test that schedules the job but the job never leaves the pending state. I have tried various configurations of waits/background threads to see if freeing the UI thread is what's needed but haven't had any success.
It also doesn't appear that Google has surfaced anything to properly test the full flow of this component which is surprising, given how they seem to be forcing everyone to use it as newer APIs are released.
I've seen What tools are available to test JobScheduler? but it's difficult to automate with adb (and I'm not interested in answers that use it).
Does anyone know a way to end to end test a JobService with the JobScheduler using Instrumentation tests?
Thanks to the Google devs being very responsive to answer my question here: https://issuetracker.google.com/issues/62543492, it's now clear how to do it!
It appears that part of the set up of the instrumentation test examples they provided is setting the running app as active and mostly learning about job state via cmd jobscheduler <command> invocations on the shell from the test
try {
SystemUtil.runShellCommand(getInstrumentation(), "cmd activity set-inactive "
+ mContext.getPackageName() + " false");
} catch (IOException e) {
Log.w("ConstraintTest", "Failed setting inactive false", e);
}
See the provided InstrumentationTestCase subclass they posted in the bug notes
When I run android CTS full test using below command
run cts --plan CTS
Every time it shows different result for some of the packages, I mean some packages some tests passes/fails randomly every time I re-run full test. But when I run package individually (The package in which some tests failed), all the tests passes in it.
Why I am seeing this behavior?
Environment:
OS: Android L
CTS version: 5.1_r7
It happen some time some test failed randomly because some time that test condition is satisfied some time not and some time because of timeout test may fail.
Some cts tests involve specific timeouts set for some event to occur. For example if you are running cts test related to data calls like turning mobile data off/on and timeout to get mobile data connected is set to 10 seconds, then some time this test will pass and sometime it will fail. In this case, increasing that timeout will resolve this issue.
Regarding issue of test case failing when running multiple packages, there could be possibility that test case before failed one has not set device in a neutral/original state for next test. It is a good practice to revert all changes made during a test while exiting a test case.
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.