11

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?

halfer
  • 18,701
  • 13
  • 79
  • 158
Reuben Tanner
  • 4,470
  • 1
  • 26
  • 44
  • If this isn't getting enough attention, don't forget you can add a bounty to it. (We tend to discourage requests for upvotes in posts here, but at a stretch one could put them in the comments, where they are not a distraction for future readers). – halfer Jun 11 '17 at 19:25
  • 1
    When I made that edit, the question wasn't eligible for a bounty – Reuben Tanner Jun 12 '17 at 15:07
  • I've opened a feature request with Google about this: https://issuetracker.google.com/issues/62543492 – Reuben Tanner Jun 12 '17 at 21:33
  • Why are you trying to be confined to the library implementation? You do not want to test whether the JobScheduler works as expected, right? Because that's not your job. Instead, mock out jobParams and perform assertions on your `AsyncTask`, what's the issue there? – azizbekian Jun 13 '17 at 04:49
  • I want to test how my code and the JobScheduler interact, it's not at all the same as testing that the JobScheduler works. It's no different than desiring to test the full lifecycle of an Activity. – Reuben Tanner Jun 13 '17 at 13:09

1 Answers1

4

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

Reuben Tanner
  • 4,470
  • 1
  • 26
  • 44